Hi everybody. Welcome to the Fedora track, I guess, at DefConf. And so to start the day properly, we'll be talking about Debian. So just to introduce myself, my name is Stephen Kitt. I'm a Debian developer, but I also work for Red Hat. It's not incompatible. My day-to-day job doesn't involve packaging, but my day-to-day job does involve running Fedora on my laptop. This is one of the things I like, and it's part of the freedoms we have in free software is to be able to modify stuff. And so I started looking at Fedora packaging. So this talk is going to be about my thoughts as I discovered the Fedora packaging stuff. I'm going to be talking about Debian as well, because I imagine lots of you aren't familiar with what goes on in Debian. So if we want to compare, it helps to know what I think is important in Debian and what I like about packaging there, and then look at how things are done in Fedora, at least how I understand things are done in Fedora. I don't have answers. If you think I'm saying I have answers, I'm probably wrong. See the quote up there. Lots of this stuff is quite complicated, but the underlying thought behind my talk is really that distros are getting more and more complicated. We've got more and more work to do inside distributions, but distributions aren't exciting as they once were. So it's harder to get people to join the effort. And so I think what we need to think about focusing our efforts more, doing things in the right place so that we avoid duplicating. I think this perhaps is an extension of the keynote, extending collaboration beyond the Red Hat distributions to other distributions. And Debian is just the example because that's what I know, but I think it applies more generally. Some caveats. So you can assume I'm wrong about Fedora. This perhaps is my way of getting into the community by saying stuff that's wrong and being corrected. If I point something out in Debian, don't assume that I'm saying that I think it's missing in Fedora. It's just that I think it's interesting in Debian. And of course Stockholm Syndrome, I've been using Debian for over 20 years, packaging for quite a long time. So if I think something is nice, maybe it's just because I'm used to it. How I came to packaging helped set the scene a bit. So I went to university in the mid-90s in the UK. And back then that meant Solaris on spark stations to a large extent. But this was just at the time when Linux was becoming usable vaguely on the desktop. So I was running Slackware 3. And it was great to be able to run or at least try to run some of the software we used for our studies on my own computer because it meant not having to go to the labs all the time. Being able to work from my student room and so on. And so that's how I got into sort of porting package, porting software at least. This was also a time when software development in the Unix world re-exploded in some way. And so lots of students, me included, were interested in running new software like MUT or SLRN or JED or Lix. And this was also a time when storage was expensive still. So we had small quotas.  So you had to compile it in your own home directory. But that meant that you were eating into your quotas. And so with some friends at university, we set up with the agreement of the university as well. We set up the system where we had a shared home directory for hosting software. And so I started packaging software there using GNU Sto. And then I joined the administration team for the university, and the student hosted computing services which are still called TARDIS at Edinburgh University. And so I did more Sto-based packaging there. Then in the late 90s, I won a competition and won a bunch of CDs with Debian on them. And I started using Debian and never looked back. Then I became a Debian contributor. So in Debian's definition, a contributor is anybody who interacts with the project in some way. So I started filing bugs and that made me officially a Debian contributor. Then I started maintaining a package. The usual story, some software got orphaned that I cared about. In this case, it was the joystick calibration tools because I like playing games on my computers. And so I became the package for the joystick packages and actually became the new upstream for that as well because it had been abandoned upstream. So I now maintain Linux console tools. So that's input attached, JSCal, JSTest and so on. And then eventually I graduated onto the next level, which is Debian maintainer. That's when somebody in Debian entrusts you with packaging your software with supervision. If you're just a Debian packageer, every time you upload a package you need to get sponsored. There's the same kind of mechanics in Fedora, as I understand it. You need somebody to check your package and upload it for you.  This also gives you access to some of the benefits of being in Debian, like for instance access to an LWN subscription, email from Facebook and Google recruiters, and access to all of Valve's catalog on Steam. Which I find quite ironic given the freedom values in Debian, but never mind. As a gamer it was quite interesting. And then I became a Debian developer because I think that's a bit like a trusted packageer in Fedora. Once you're a developer you can upload anything you want to the archive for any package. So if you try and do it for something that's not yours, there are social barriers to that, but technically you can. And you also get to vote on all the major decisions in Debian. What's it like when you're actually developing in Debian? So to cover that I thought I would go over the dashboard that we have for packages in Debian because if something appears in the dashboard it means that somebody took the time to write the code to put it in the dashboard which means that somebody cares about it. And cares about it enough to do all the social engineering and so on that goes into getting stuff changed in Debian. So you can see here this is the top of the screen with my name and then the list of packages, source packages on the left. So I have 57 source packages in Debian main. I'll explain what that means just a bit later. But going through all the columns shows what's important in Debian. So obviously bugs, I think that's the same everywhere. And we have two big categories of bugs, RC bugs and the rest. RC bugs are ones where if your package is important enough you'll delay the release, otherwise your package will just be chucked out of the distribution. So you really need to care about those, keep that at zero, otherwise your package is liable to go away. And the rest is, well, stuff you haven't got around to fixing yet. Then we have version information. So this is the versions of the packages that we have in Debian and in a favored downstream Ubuntu for whatever reason. And so we have the stable version which is the one that we still support and provide security fixes for and important bug fixes for. And then testing which is the next release that's coming along. So we are in the process of freezing it, so it'll be coming out soon. Unstable which is the staging grind for everything. And then experimental which is where you upload things that aren't supposed to be part of the release yet. And so version numbers progress from the right to the left and then from the left to the right into Ubuntu again. We have also another type of versions which are the ones underlined there on the left. Backports, so for some software where the release cycle of Debian is just too slow we provide backports that are a bit like Apple in a way. So users of Debian stable, the last release can install a newer version of the package quite easily that's been built for stable. We don't have any dependency issues but they get access to new features and that package there in particular is the gog.com downloader which needs to be updated every once in a while. And the excuse thing, that's a linked page that tells you why your package hasn't migrated from unstable to testing yet. Then we have a VCS column. This is a link to where the packaging is stored and this being Debian there are a number of different ways to use your package. I tend to use Git. With one specific workflow, this being Debian again, there are different workflows even if you use Git. And the tick mark means that your VCS is up to date with what's in the archive because sometimes people forget to push their repos when they upload something to the archive. Then we have the buildDs, buildDemons and this links to a page like that which shows the state of your package on all the architectures in Debian. And this is a big difference with Fedora in Debian. We have tons of architectures. The white ones at the top are release architectures so if your package doesn't build on one of these then you might get kicked out of the distribution. So there's a bunch of stuff that we care about there that can cause pain sometimes like RML at the top for old ARM systems. These are so old that they don't support certain C++11 atomic operations and so there's software now which will never build anymore for these machines. We have new architectures like ARM64, MIPS64, YELL, PPC64, YELL and then older ones that are slowly dying well like RML, perhaps MIPS I guess. And then the gray ones, they are either upcoming architectures that aren't ready yet like Spark64, PPC64 or old architectures that used to be release architectures and have been demoted like alpha or architectures that have never really made it like SH4. And so it's nice to know what's happening on these but it's not bad if your software doesn't build on them. But if you care about an upcoming architecture you can keep an eye on it there and the portiers are always glad for help. Going back to the dashboard, the next set of columns are quality metrics and a bunch of different tools that run automatically on the whole archive every so often and check things for us. So Dev Check is a set of basic tests for package dependencies. Lintian is a bit like RPM Lint. It does lots and lots of different checks of varying types. It could be spelling fixes, updates or licensing issues or whether your software uses Bind Now or Pi, things like that. And in Debian it's become the way of driving change. So we have this weird thing in Debian where Debian policy, which is the equivalent of the Fedora guidelines, isn't normative. It's descriptive. So things end up in policy once they're the consensus. So if you change behavior, if you want to get a change into Debian, you convince enough people that it's a good thing and then once it becomes the norm, it's codified in policy. You don't change policy first to drive change. We used to drive change through the release team and release goals. That's not happened over the last few releases. People are thinking about it again and there was discussion of the last Debian conference. But in practice, what happens now is if you want to drive change or introduce a new check, you add it to LinkedIn and then people see these warnings on their packages and so if they care about their package, then they tend to fix them. This isn't address packages that have dormant maintainers or maintainers who don't care so much, but that's how change has... Well, it's the emerging way of doing changes in Debian now. Then few parts. That's a tool which installs and uninstalls your package and makes sure that that happens cleanly so you don't leave anything behind. Then we have CI. I think this is probably fairly similar to the CentOS CI that was discussed in the keynote. The idea here is that you can add tests in your package, what we call auto package tests, that are run externally to your package. So these aren't tests that run during the build. These are tests that run after the build. We take the artifacts that the build produces, install them and then run your tests, along with any other package you want. This is really useful because, for a library, you can write an auto package test that checks that once your package is installed, you can link code that uses your library and this is a better test than a build test because during the build, the build knows where stuff is, but you might still have messed up your package and users can't use your package. So I maintain tool chains in Debian and this is one of the things I've been meaning to do for the last several years is add CI tests for my stuff, but I haven't got around to it. Rep, that's the reproducible build stuff that Hogar talked about yesterday. So a tick mark here means that your package is reproducible. If it's in brackets, it means that the current version of your package hasn't been tested yet, but that the previous one was. I think this is really important in Debian and go and watch Hogar's talk if you didn't see it yesterday. Then we have another column, which is pop-con, the popularity contest. So this is a fairly meaningless number, really, which measures how many people have installed your package and are willing to tell the world about it. Even installed doesn't mean all that much because lots of people have got tons of packages installed that they don't use and we sort of try and measure that, but it's imperfect. Things like Rella time and so on mean that we can't measure things very well. And so it ends up a bit like the pile of books that you've got at home that you mean to read one of these days. But it's still useful to get some measure C trends if your package is going up or down and then when we decide whether to remove something, obviously if something's got a high pop-con, we'll think about fixing it rather than removing it. But if it's got a low pop-con, lots of RC bugs, then it's nice. Just to give you some measure, the highest pop-cons are around 200,000. And then finally, the last column in the dashboard is the watch column and so this is what upstream is on. So we have a flag in the package. Well, a piece of information in the package that tells the tools that look at this how to check what the current upstream version is. And you can see here whether you need to update your package or not because same as in Fedora, we try to keep up with upstream as far as possible during Debian development. So that's all the columns I've covered and if you scroll down these dashboards, there are a number of different sections that reflect different things in Debian as well. So the first one is the main section. This is the real Debian distribution. What is DFSG free? So free according to the Debian free software guidelines. It matches our licensing, all the dependencies are free software as well. All the build dependencies are free software too. Then you have Contrib, which is not officially part of Debian GNU Linux but is hosted on the repository. So this is free software but that has either a non-free run time dependency or a non-free build time dependency. So for instance here, this is Bazalisk 2 which is a Macintosh emulator. To run it, you need Macintosh ROM which is obviously non-free so it can't be in the main section. Then we have... So that covers the different types of software. There's also non-free which is completely non-free stuff like the NVIDIA drivers and so on. Or firmware that you unfortunately need to run lots of computers nowadays. Then we have different sections that cover different ways software gets into Debian. So non-maintainer uploads. This is software that I've uploaded even though I'm not the maintainer of the package. So usually that's to fix an RC bug when the maintainer isn't responding for software that I care about. Then we have sponsored and other uploads. So that's software where someone else has packaged the software and has asked either me specifically or the community in general to review their package and sponsor it for them. And this is a great way of getting new contributors into the community slowly without the sort of administration that's involved in joining Debian properly. They can start packaging and get sponsored. And you tend to sponsor the same packages several times. And that creates relationships between maintainers. And eventually you hope that the maintainers will graduate to become Debian maintainers or Debian developers. Then we have another section which doesn't correspond to anything in the archive. This is intense. Well, this is more about the future of packaging. So own WNPP bugs. And just now I can't remember what WNPP stands for. But basically it's the list of bugs that say I intend to package this and I want this to be packaged for me. I have an ITP for Piper because I maintain libratbag and ratbagd so it makes sense to have Piper in there as well. But Piper isn't really ready yet. So it's still sitting there. And then finally, the last one is packages for which I, as a Debian developer, have given others Debian maintainer rights over. And that pretty much covers the dashboard. So let's talk about Fedora now. As I said, I work for Red Hat. So when I joined Red Hat, I got a laptop provided for me with CSB. But my colleagues told me I'd be better off running Fedora for the kind of work I'm doing. Well, they were right. Fedora turns out is a fantastic developer distribution. And I find it absolutely great. You go and look for Fedora on the internet and you end up at getfedora.org and it's a very, very focused website and a punchy message, choose freedom, choose Fedora. That makes me think of train spotting. And lots of people choose not to choose freedom. They choose something else. But who needs reasons when you've got windows or something like that? Look at the quotes on Wikipedia.  So you're just a couple of clicks away from an ISO. You stick that on a USB key and later you're running Fedora, which is fantastic. Discovering Fedora as a user, like I said, in focus and you can see that in the distribution as well, it doesn't claim to do as many things as Debian does, although Fedora now has a huge number of source packages as well. But it works really well. So that's testament really to lots of people. But distributions, Fedora specifically, other distributions, upstreams, it's not hard to make a Linux system that sort of works. It's still an awful lot of effort to get a distribution that works really well and Fedora does work really well. Fast updates. And of course at home I tend to use Debian testing, so I'm on a rolling distribution. It's a bit more like Arch Linux than Fedora. But still getting a stable distribution out every six months and keeping it running all the time with stable kernel updates and so on is no mean feat. And it's a great development environment. I find it quite interesting that Fedora has Eclipse packaged, Debian has NetBeans packaged and has been trying to have Eclipse packaged for years, but it's a really painful thing, packaging Java in general, but Eclipse in particular. DNF, so that takes some getting used to compared to apt. There's some good things about it, like rollbacks. I find that quite fantastic when you need to use it. The way it doesn't recover well when it crashes, that's not so good, but it's been discussed on the mailing list, so it'll improve, I guess. And then RPM Fusion, so that's Fedora's part of hypocrisy, I guess, a bit like Debian's part of hypocrisy with contrib and non-free that aren't part of the distribution but that lots of people end up needing anyway. Fedora has RPM Fusion for that. That's out of scope really. And then like I said, I like being able to use my freedoms and that means packaging stuff. There's stuff I package in Debian that's not in Fedora that I use. And so I started looking at packaging. And this is another area where you can see Fedora's focus and the effort that's been spent on websites and so on. You go to the Fedora website and there's a website dedicated to what can you do for Fedora. And it's not about just packaging, there's a whole bunch of different things. So when I was preparing this talk, I went back to the site to take some screen grabs and the one that came up for me that time was design. So I would like to be able to design, but I can't. So nope, nope, nope. And the second one that came up was packaging. Yes, that's exactly what I was looking for.  Yes. And that takes you to a wiki page. So the design changes a bit, but it's still... Right, okay, so somebody in the audience points out that there's a new version of wiki media that's being set up. So this should improve. But even despite the deficiencies of the wiki medium here, I still find it interesting that the first thing you land on is a flow chart that shows you the whole process from start to finish. So you know what you're getting into. And then it goes into detail and the detail is this. And I thought it was interesting to go over that because it shows what's important to the community. How you get people involved in your community shows what's important for your community. And the first thing when you want to get involved as a package is read the guidelines. And you get links to two pages, one that shows you the basic workflow for building a package and then another one that goes into a lot of detail. And you really need to read both. And I think that's very good that if you want to... It says that you want to drive the level of quality, at least for packages, if you recommend that they start by reading all the guidelines first. And another thing I like about the guidelines is that they focus on one way of doing things. So when I started looking at Fedora packaging, this was RPM build. Now it's Fed package. So that means that things change in Fedora as well. But you don't end up with the same kind of situation as you do in Debian where newcomers come along and they say, how do I package this stuff? And they get a dozen different answers. And Fedora, there's one answer, Fed package. Then you start doing the administrative stuff. Create accounts. Join mailing lists. And this is an important part of being a member of a community on the mailing list. So if you join them at this point, you've got nothing to say, so you'll start receiving email and you start reading stuff and getting a feel for the community. Ensure suitability. So this is about licensing and stuff like that. Before you start work on your package, make sure that it's not going to be for nothing. This is quite complicated. I saw some reviews just recently where somebody had gone through the effort of doing all the packaging and in the review, it was pointed out to them that there was a file somewhere that had a bad license and so the package couldn't go into Fedora. Understand responsibilities. This is important as well. If you become a package maintainer, it's not just about getting your software, you're interested in, uploaded into the archive and into Fedora. It's about providing at least some level of support for afterwards. You might receive bug reports and stuff like that. You need to react to them. Then lurk. So it's not stated explicitly like that on the Wiki page, but that's the intent really. Stick around. Have a look at other reviews. See what other people are saying before you pipe up and introduce yourself and stuff. Then set tools up. So that's easy enough. Well, for somebody with a technical background, I guess at least. And only then make your package, upload it, request a review. And at this point, you've put in all the effort and so there's a fair amount of chance that your package will end up in Fedora, I imagine. And so at this point, it makes sense to tell upstream. And this is something very important, I think, as well. And a focus I've perceived from reading the Fedora documentation is stick close to upstream. And I like that message because it means less duplication of effort. If you can get stuff done upstream, then all distros benefit from it.  And it's also useful for upstream to know that their package is going to be in the new distribution. So they're going to end up with a whole pile of new users potentially and they might be getting new bug reports, possibly for a new version that's whatever version has ended up in whatever release people are using. And so it changes expectations for some upstreams. And I guess perhaps in some cases at this point you'll get a reaction from upstream saying, no, please don't. Then next step, introduce yourself. So at this point you pipe up on the mailing list and say, hi, this is who I am. Again, part of community. And I guess this is part of the friends thing in Fedora. And then the last two steps are actually get your package in the distribution. So get sponsored. And finally, you've done all this. So you add your package to the SCM. And then it goes in. From all this you might have gathered, I think community feel is very important. So during this process you get a chance to measure it. So I was hoping to be further along in the process than I actually am by the time I gave this talk. So I do have some packages that I'm working on but I'm trying to stick close to upstream thing. And there are changes that need to be made upstream before the packages are suitable for Fedora. So I actually haven't gotten round to the request to a review part or introduce myself on the mailing list part. But I am working on it. And I have been lurking a lot. So the mailing lists, you get told to join Fedora Devel, the announce list. And if you want, if you're keen, the packages list. So not many mailing lists, but they're fairly high volume. And if you compare that with Debian, Debian has Devel which has a reputation, a certain reputation which it doesn't really live up or down to depending on the way you look at it. But people say that Debian Devel is a very high volume mailing list. It isn't anymore. It's much less than Fedora Devel. It's really, I think the SystemD stuff killed it, to be honest. Which is a shame. But we have lots of other mailing lists with more specific focuses. First is there's a Debian mentors list which is dedicated to helping people with packaging. And what I find very interesting in the Debian community is that you don't just get newbies asking for help on that list. You also get experienced Debian developers who are discovering new packaging techniques or packaging things that are in new areas. First is they might have been packaging lots of C stuff and they need to package a Python module at some point and they don't know much about it so they'll go and ask there. And it's a place where you can be vulnerable without it mattering. You can say, yeah, I've got 20 years experience in Debian but I don't know this stuff and nobody will look down on you for it. And the feeling I got from the Fedora mailing lists is that they're all very polite, even in the flame wars which happen every now and again. And you do see the difference with lots of people on the mailing list who do this professionally. Well, like Matthew Miller said in the keynote, there's only a third of Fedora contributors who are employed by right-hand but I do think that makes a difference and you don't get all the snipers that you get on Debian mailing lists, people who are not actually contributing to the community but who will take any chance they can get to flame on the mailing lists. And that makes for a more welcoming atmosphere. IRC, so I haven't spent all that much time on hash Fedora but I thought it was very, very, very interesting that if you try and join or if your IRC client rejoins and you haven't actually had time to register, do the register stuff or give the password for your nick, you end up on Fedora unregistered. And I guess it shows the importance that is placed on having stable nicks, owning your nick, owning your reputation or whatever. And then the review queue as well, so I've been looking at lots of other reviews and again that shows the kind of community feel and the reviews tend to be mostly constructive. It's really, well, the impression I get, there's not much, you know, if you make a mistake, it's just a mistake.  And I also find it very interesting that Fedora does quit pro quo reviews. In Debian, the reviews that are done before a package goes into the distribution, they aren't technical, they're just for licensing and it's the FTP master suite, well, the FTP team. So a small number of people get to review all the licenses, it's a nightmare for them. Whereas in Fedora, there's a technical review as well as the licensing stuff and lots more people do it and it means that you get more cross-pollination between people. People can discover techniques more readily and of course it shares the workload. One thing I did notice is the difference in attitude towards teams, well, in Debian we call them teams in Fedora, I think it's more six in the working groups. So a bunch of people who are interested on the same kind of packages and get together to do stuff. We both, Debian and Fedora have the same problem of wiki pages for old teams that have tumbleweeds. But I thought it was interesting that there's a very different focus. In Debian, we use teams a lot to welcome new contributors. So if you're interested in packaging Java, we'll tell you to go and join the Java packaging team and that's where you'll learn the packaging practices. You'll also find sponsors and the feedback you'll get will be very relevant because these are people who encounter the same problems that you'll be encountering. In Fedora, at least on the wiki pages they explain how to join the project, there's not a single mention of SIGs or teams or whatever. I find that interesting. I don't know if it means much, but on to the actual packaging itself. The big difference I saw is what constitutes your reference, source packages. In Debian, the reference is, as far as possible, the upstream tarball, or a tarball that's built from a Git tag or whatever. And on top of that, the Debian packaging. In Fedora, the reference isn't what upstream provides, at least the way I understand it. It's the source RPM that's produced at the end of the build. There are good things about that and bad things. I won't go into the details, but I thought it was an interesting difference. Then there's more technical stuff about the distribution layout. The stuff that I've been having trouble with is Slashlib versus Slashlib64. In Debian, we use Multiarch. To be honest, I think Multiarch is a much better approach. I think it makes sense in all cases, but it's only really evident that it makes a lot of sense when you have as many architectures as we do in Debian. Then there's the LibExec thing, which I guess makes sense as well, but causes some issues with packaging that we never encounter in Debian because we don't have LibExec. And then helpers. So these are all the tools that go around the packaging. Basically, RPM macros in Fedora. And in Debian, it's DebHelper and the Galaxy of stuff that goes along there. Over the last few years in Debian, there's been an awful lot of effort put into these tools to just make packaging as simple as possible. So handle all the complexity in the helpers, which means you can get it right once, fix everything, and if there's a bug, you can fix it for all the packages that use them in a single place. I don't think the RPM macros are quite there yet. I've been working on a CMake package, and I should really be filing sending patches for the CMake RPM macros, I guess. But I think it's interesting to invest time in the tools because you reap the benefits over all the packages. And that's something that historically, people have said RPMs are nice to package because there's just one spec file, you write everything in there and that's it, it's done. Whereas in Debian, there's all these different files and there's a rules file, which is really complicated. And now there's a rules file in lots of cases, there's just two lines to delegate to DH. Another big difference I saw is in the way you handle, well, the two projects handle licensing information. And I thought this was very interesting because Fedora has the patent issue, the stuff that means that we have RPM Fusion because our MP3s and so on can't go in. The reasoning that... Sorry? MP3 playback is okay. MP3 playback is okay, right. But encoding I guess still isn't, like lame and so on. And the reason that I've read at least for this, I don't know if it's true or not, is that because Fedora is backed by Red Hat, there are deep pockets that people could go after in lawsuits. And so the patent stuff is important. And I guess this means that it's a sad reflection really on the state of licensing and the open source world that licensing issues aren't as scary. And so in Debian, we've got the opposite problem. We focus an awful lot of effort on licensing and this here is the top of the Winegecko Debian copyright file which I maintain. And the reason Debian doesn't have up-to-date versions of Winegecko is that it takes me months to go through new versions of the package and do all the licensing review to write this thing. This file is 4,000 lines long and it's machine readable but not machine writable. And you can imagine it takes me months to write and then it takes the FTP team months to review it. It's really, really bad. And this is Firefox. If you don't know the connection between Winegecko and Firefox. This is actually Firefox. Firefox is too big to fail. It's one of these packages that's too big to fail. And so it goes into distributions without much scrutiny on the licensing but there are some actual licensing gotchas in there, you know, stuff that's got the Apple license or MSPL or whatever. And Winegecko isn't too big to fail and so I have to handle this. Winegecko in Fedora says this. So we trust upstream to do their work. What do upstream say? Not much and they get it wrong. So I'm not saying Fedora should put the same, you know, go to the same lens as Debian does. I think Debian goes too far, at least the FTP. The working practices around the Debian copyright file have gone too far but there's probably something to look at there. And then trends of what does it tell me? What does my experience tell me about distro trends and what are the impressions I get from Fedora? I think all distros in the Linux world suffer from the same kind of problems nowadays. Old timers are moving on. Like I said earlier, distributions aren't exciting anymore so it's harder to renew the community. I get the impression, at least in Debian, we no longer have any really sort of big figures that are doing an awful lot of work. There are some people who do lots of work quietly. Some people who make lots of noise but don't do much work. At the same time, Open has one, Open Source has one, Free Software has one and so we have more and more upstreams, alternative package management systems, you know, like NPM, RubyGems and so on, that mean that it's not unusual now for somebody to come along and say, hey, it would be great if we could package this. Oh, and by the way, to get this in, you also need to package 250 new dependencies. I had to look at Keybase a while back when it was still a Node.js thing and they had around 200 dependencies that needed packaged, so Keybase isn't in Debian yet. Alternative distribution models as well. This is all the stuff around containers and flat packs and so on that they don't make distributions irrelevant, but they do mean that more people are doing the kind of work that distributions do. Perhaps there's an opportunity there. Quality, quality, all right, all distributions have put in a lot of effort in getting packaging better, but there's not that many people who look at what actually goes inside the packages, you know, until a security bug comes along. And in Debian, there's been an awful lot of discussion on the mailing list about packaging Node stuff and there's a guy called Pirate Proven who started packaging GitLab and you might think of GitLab as a Ruby thing and yes, it is a Ruby thing, but it also uses an awful lot of Node and so he's been packaging lots and lots of Node packages. He's got over 400 packages, Node and Ruby already and sometimes somebody goes and has a look, you know, when he files an intent package bug, somebody goes and looks what's in the package and says, this is silly, there's no point in packaging this, what we should be doing is patching the reverse dependencies so that we don't need this and you end up with Node packages that look like that, so you can't read the details there, but it's one package that only exists to check if another package is installed, right? What's the point of having dependency management in your distributions if you end up packaging stuff like this? What are we good at? So going back to the main Fedora website, Freedom, Debian I think and Fedora, we're both good at ensuring that our users have the four freedoms. So licensing, what are we good at?  Fedora says stick close to upstream, but there's stuff that all distributions do and perhaps we'd be better off if we were telling upstreams how to do them. Check your licensing, how to build software, how to build distributions, which is taking all these moving things stable out of them. And you need to do that for distros, you also need to do that for flat packs and containers and so on. And lots of people are going to be learning the same lessons that we've been learning over the last 20 years. Handling fixes, getting security fixes to your users without breaking their production and fixing important bugs as well without breaking their production. We know how to do that in distributions. Lots of people are going to be learning how to do that again and again and again. User-oriented quality, this is getting the configuration right, getting something that's usable quickly, but that can be adjusted to the user's requirements easily. We do that an awful lot in distributions. And other stuff, more technical stuff, like understanding what it means to be stable, so ABI stability. This is something, you know, lots of people in the Debian world they see unstable versus testing versus stable and they don't understand what stable means and they think that unstable means that it's very buggy and it's going to crash a lot. It's not about that, it's about ABI stability. And there's stuff going on in Fedora that's very interesting on this front. Stuff that Dojie Cicadilly is doing with Libby Gale and stuff like that. There are tasks on Taskotron that will tell you if your RPMs are breaking ABI contracts. I think that's very, very interesting. But there's stuff that doesn't mean much if we don't educate upstreams about it because we can't cope with changing ABIs if the upstreams don't change their SO names and so on or, you know, their node versions, etc. What are we not so good at? Well, getting upstream involved. I don't know if it's something that we're not good at or if it's just that we get lost in the day-to-day grind of getting distributions out and so that gets put on the back burner. And maintaining quality, this is something that we all struggle with. Packages that are old and un-maintained but where there's just enough maintainer activity to keep things ticking along and it just gets old and crafty and... But in all that, there's lots that's not specific to any given distro. So there are lessons that we learn that are valid across distributions. There's also lots that's not specific to the fact of being in a distribution at all. It's equally valid just for general software engineering practices. So in conclusion, let's define the future but define it together. And continuing on from the keynote this morning about collaboration between REL and CentOS and Fedora, I think there are lots of opportunities for collaboration beyond that. And that's it from me. If you have any questions, the floor is open. So do you see some space for collaboration between Fedora and Debian on some level? Yes, the question is, do I see space for collaboration between Debian and Fedora? Yes, definitely. And I was quite interested to see that Hans de Goethe, or sorry if I mispronounce the name, has given a talk just afterwards because he's one of the Fedora people that I saw collaborate with Debian a while ago in the games teams. So I'm a member of the games team in Debian and there's a games sig in Fedora. And at one point, there was some collaboration between the two and I think there's space for more of that. I think there's also room for not necessarily collaborating directly on the distributions themselves but coming up with ways of explaining to upstream how to do things better. And I think that would have more weight if it wasn't just Debian telling people that they're doing, well, not necessarily doing things wrong but they could do things better, but if all distros somehow came up with another standard. There's another question. Yeah. We do work together and talk to you. Licensing is an interesting area because I agree with you that Debian is much more systematic about licensing. But in order for those of you who haven't been there, there are some people who are interested in licensing and take it seriously. And we do often find ourselves working to maintain some of the distributions because like I said, you can't just be slapdash with your license if you don't take care of it. So I think it goes on that it's not very visible necessarily. Yeah. Yeah. So I'll repeat the comment. Well, summarise the comment for the recording. So basically Adam was saying that there is collaboration that goes on in the background between individual packages, individual maintainers. And there's also an awful lot of collaboration that goes on just because Fedora Packagers are also upstreams and likewise Debian developers are also upstreams on the same projects. And so there are people involved in GCC and so on, yeah. And there's collaboration that goes on. And he was also saying that licensing stuff does have more weight if comments on the license come from multiple different distributions, yes. And so instead of dismissing one distribution, they just dismiss two distributions. Does everyone else just package it without complaining about the problem? Yeah. So the comment was that in practice it's just Debian and Fedora talking about stuff like licensing. And other distros, I guess, care less about it. Yeah, for AURs, for instance, in Arch Linux. And so people just, instead of dismissing one distribution, they dismiss two. Yeah. Yeah? Yeah, so I wanted to ask, I work on upstream software and also I think it's in Fedora because I work on Fedora. But I'd also like to see it in Debian. I don't feel like you're really covering the spectrum of users in this in Debian. I'm wondering, is it in Debian, what's the ratio of packages available for packaging versus people who want to package? Do something good and wait until the developer comes along and sees this tractor and does it or should I become a Debian developer? Or what are you going to say? Yeah, so the question is about getting upstream software into Debian and if there's a way of measuring the ratio of stuff that's waiting to be packaged in Debian versus available workforce, I guess, and whether you need to become a Debian developer if you want to get your upstream software into Debian. So I'd say, to answer the last question, becoming a Debian developer is probably always a good idea if you're interested in that. There is one way of measuring the ratio of interest to available workforce which is the WNPP page which lists all the packages that people have pledged to package and more importantly all the packages that people have asked for and that's, it's huge the HTML for that page is over a megabyte in size, it takes ages to load in a browser so yeah, there's an awful lot of stuff that people want in Debian and there aren't enough maintainers so, and yeah it brings me to another thought I had when I was preparing this going back to where I came from in my packaging history, what's important is actually getting software into the hands of end users, packaging isn't an end in itself it's a means to an end and so, I hold lots of hope for stuff like flatpack and so on there will be another way of getting software into the hands of end users and perhaps more driven by upstreams because upstreams will be able to, well hopefully write flatbacks that will work across distributions but yeah, there's no miracle answer really, you can ask for a package try to get users who are also Debian developers interested in your software, usually once a Debian developer starts using your software a lot appears in Debian but if you just file an RFP request for a package it's liable to just sit there, yeah so we have a percentage of people who are end users, where end users can upload and this is a place where a lot of interested people can review packages they usually just do initial package off because they don't really know anything, but if you do a package I'm doing it, I'm showing it to the developer, they need to be triggered and they will give you stuff and give you all sorts of comments that you can express or this can be easier, just make it easier to trigger yeah, so for the recording there's another way of getting a package into Debian which is to start the packaging work yourself and upload it to mentors.debian.net or .org a camera which it is now and that's a way of getting your package up for review and then you send an RFS and you're more likely to get interest that way because you've actually put in some work and people will go and look at your package and tell you how to improve it and once you've got people hooked like that it's a bit like when you start in an auction they're liable to go all the way to get your package into Debian and that's also a first step for you to becoming a packageer and maintainer and so on, yeah Yeah, so the question is Yeah, right, yeah, so yeah so the question is how can upstreams get changes in Debian packages that's a really, really tough question so the last point you made about getting newer versions that's easy enough in theory you file a bug asking for a new version if the maintainer is not responsive it's not likely to move all that much but if you disagree with the way the Debian package is done that's a very, very tough situation because there isn't really any conflict resolution process in Debian that works and not something well, not something that you can invoke as an external someone external to the Debian community there's a TSC well, the technical committee, yeah, thanks technical committee but that's more for conflict between Debian developers they might step in for upstream versus Debian, I don't know probably not it's not something you want to try I'd say, you really need to find some Debian maintainer who's interested in your package and is willing to be your advocate in the project and that's, yeah, last question yeah there are as many well, so the question is so Debian, does Debian perceive Ubuntu as a derivative so yes and what is the relationship between Ubuntu and Debian basically and the answer to that is there are as many answers to that as Debian developers I think and probably more so it's a point of contention some people in Debian consider that Ubuntu sort of leeches off Debian others consider it as a good thing, I think it's probably overall a good thing the more users there are of Debian stuff the better things are it's a complicated relationship if you look at some of the core stuff that happens in Debian it is driven by Ubuntu people like Docko who's the GCC maintainer he's a canonical employee so this complicated, I think things have changed recently well, over the last few years as well with the change of focus in canonical so it's perhaps less of an issue now than it was at one point they appear in the dashboard but there are other derivatives that are important as well like Mint and so on so yeah, that doesn't really answer the question but I don't really have an answer, sorry well, thank you very much for your time


Trini girl natural let the struggle commence Okay, okay. We got the products girl. Let's go. Let's keep it going. All right, so Section me Take care of problems. I knew better than to try to put that much into that clip But love her Africa. I'm too cute. My uncle's had combs like those. I don't have one doll So we see how that goes because I still don't have one. Yes, I didn't learn my lesson Okay, I'm moisturising. I can do that I think I'm not moisturising my by fast I'm parking with me She's planning with her finger I love that because I might be a cool person So I'm just going You won't notice that I haven't done a flat twist in so long but Love this. Let's go The easy parts of applying product that I can do this I feel like I'm sipping it down From where it goes Focus is coming out decent So I'm not doing it over We're gonna stay with the sister Okay, I guess we've done everything except the back Let me try to get there So this is it so far and I guess we'll see what happens next stay tuned I'm stay tuned Um Wish me luck Okay, so I'm back Three days later three workouts later. Let's see what's going on So we all done. Yeah, you all got that part Um No scarf. The scarf probably would have been a good idea. I know that I'd look at it, but Uh didn't look at that part At my DIY oil mix Let's pull them off. Yes, that was easy Oh my Nibbers Good definition And This is the side that was kind of um twisting the wrong way, but so Let's see what's the difference Oh, she just picked it We bought that nice I think I'm gonna separate a little bit first because I don't quite understand she Listen, no, it should be like super like curly. So I guess that's good I guess that's the look that she was going for I like that. I got the hand of the twirl thing. Look who's twirling Twirling I just don't have patience for like fluffing and separating and all that stuff. I really don't I'm over it. I guess I'm gonna get to it. So I have this and this That bees out So I've never picked before in my life I really don't like this. I'm not a picker. Let's just pretend that this is all picked because I'm over I do kind of like it. I like the curly short Now I'll be taking off this pink Use that I'm gonna use a little more of this And hopefully it does not go awry So I like it it's a success cheesy you got me to the farmer's ladder and we did it I know I could bluff more, but I think it's kind of cute just like this And I I realize I'm not about to fluff it and separate in life either.  Nine problems as it is So let's just end it on that note. But before we do give away Give away announcement. Give away winner announcement The winner is You're the winner. Enjoy. I know you love natural air products. I know you're gonna love she sent it Definitely. Let me know in the comments after you tried it what you thought of it And congratulations again, please email customer service at she sent it dot com With your name and your mailing address and the subject line trinity girl natural She sent it giveaway to the collector prize Congrats and enjoy from trinity girl natural and from she sent it and thanks to everyone also who participated Thanks for all your support and I look forward to doing more giveaways in the future as well as more Pro reviews and demos. So that's it. I've kind of action packed video for you guys. I hope you enjoyed Thanks for watching and I'll see you in the next one


Everybody forced here got a personal box of 2022 flawless football hobby for Michael s Here we go Michael party time party time first up rookie showcase Quad relic six of ten of johann dotson Ball two patches of top glove on the bottom left Jumbo rookie patch guard is sauce gardener 25 Barely two color over there green on the right side sauce gardener 25 Three-color patch auto javante Williams nine of ten Javante player worn patch auto flawless performance is autograph Michael Vic six of 15 At seven touchdowns that day right six passing in a rushing touchdown before passing in two rushing. That's what it was my bad Vic to 15 Trayvon Walker RPA 3 at 15 Rare Trayvon Walker RPA The flawless RPA has been not NT RPA is interesting. So is that his like true RPA is the flawless one? I Would assume it would have to be then right nice Trayvon next up is a Bruce Smith autograph numbered four of ten flawless achievements career sack record be set it back then Distinguished patch auto Troy Paul Amalu 15 of 20 awesome Paul Amalu player worn patch auto All the mallu head and shoulders and shoulders Ruby Jim 16 of 20 Jared golf a diamond guarantee here for the box Golf out of 20 16 to Jersey number. Yeah, thumbs up for Spencer if he's watching Sapphire Joe Shiesty seven out of 15 Shiesty sapphire and back of the box has a Desmond Ritter rookie debut signature is numbered three of 25 I Think Falcon's going to play offs this year Ritter three of five on the rookie auto You go Michael not to hit on the back looking for necessarily hopefully Ritter can turn it around a little better Yeah, open for a party there, of course appreciate the order we'll get those cards out to you


Peripheral arterial thrombosis is a common complication of COVID-19 infections. There are few affected treatments available, and many patients experience amputation or death due to the severity of their condition. This article was authored by A. N. Kazanzev, A. A. Devlikamova, I. O. Demetrieva, and others.


A ceremony was held at Fleet Activity's Sasebo Friday, December 2nd to frock some of the Navy's newest petty officers. It was a nice event, as most of them, it's very nice to share that day with people and be able to witness them. Especially when we see them working day in and day out, we see them studying, we see them working hard. So to see that come together today and to see them actually frock on their crows is very nice to be able to see that today. To me, it's just one further step into my career to my future Navy career now as far as 20 years. I'm not sure, but I'm going to keep going on and on and not stop them. Now that these sailors have advanced, they will accept more responsibility in their ranks and in the fleet. Seamen Kyle Pulaski, Fleet Activity's Sasebo, Japan.


We think you really know how fast I am. And you want to see how fast I am? Good morning, everybody. Today is Thursday morning when I am filming this. Wow, and my voice just cracked like I was 14 years old. Cool. We got that ball of fire coming up in the eastern sky over there. And we're about to go do some more training today. So just like yesterday, we're gonna be training on the Knuckleboom truck, loading and unloading poles. We can also load and unload crates and stuff. It works as a crane as well. It's pretty neat. And then after that, we're gonna train a little bit on the RGN trailer, the low bed trailer.  That'll be pretty neat to show you how that all works. And then after that, I'm not sure. It sounded like we were just gonna be training in the morning today, but it might be an all day thing. Not sure, not sure, but Friday I might be going out with another guy for some hands-on training. Right now I need to get some coffee into my blood because it's necessary, because it's the morning time. It's a new day. And a new day deserves a fresh cup of coffee. We're looking for Chevy. Oh, I got him. I got him. I got him. Hey, Chevy, you wanna say hi to everybody? No, you're busy. You gotta find a good spot. He's got a load to deliver. He's going to a spot, I can tell. That's good, that's why we're out here. So good morning, everybody. Good morning. It's another day. It's Thursday when I'm filming this. And today is another day of training for me. I've got to finish up my training on the knuckle boom truck. We're gonna pick more stuff up and put it back down. We're gonna unload poles. And then they wanna train me on the RGN trailer, which is what I call the low bed trailer. It's for hauling heavy equipment and stuff like that.  But maybe he meant we were gonna work on the knuckle boom for half the day and then RGN for half the day. I don't think it'll take half the day for the RGN to train on that low bed. It only takes like an hour. I'm pretty sure that's what he told me. So it might just be a half day of training. Guess I'll just have to show up and find out. Chevy, are you done? Chevy? Chevy? It's a beautiful morning out here. I love summer mornings. I lost my dog. He disappeared. He's gotta be here somewhere. There he is. You're gonna need that shovel, dad. I'm sorry. We're up to it right now, actually. Can you see it back there? We just finished our training on that. So lunchtime, I'm getting hungry. I'm gonna go and drop this wagon in the back where it belongs. And I'll take you guys along with me for that. You guys can see me do it on my own with no supervision for the very first time. I'm hungry. I usually have some snacks in the morning time on a regular day. Not the heavy, heavy equipment, but you know, heavy equipment, trucks, broken down trucks, medium heavy duty. It will put me to work on it in the future. Good points. On this trailer are rated at 11,000 pounds. Oh, hey, somebody parked a different trailer in my spot already. It was supposed to go right here that somebody else parked in my spot. I'm gonna leave the spot open for five minutes and somebody fills it up. Oh, find another spot for it, I guess. It was parked right here. So I got it in line with this trailer here. I'm wondering if I should line it up because now there's not enough room to park anything in here, but they might need this space to get back there, you know? It won't take too long. It's gotta be straight. It's gotta be straight. I'm not gonna sleep tonight when I don't get my sleep. See, these trailers aren't straight. I'm straight, very close, very close. Good enough, whatever. I'm not moving it again. Once those trailers get pulled out, they'll line them up with this then. Then we'll all be straight, or maybe they won't, and they'll all just always be crooked. There's that option too. Now, we need one big block and a two by four underneath here. We'll do the same thing on the other side. Whoever had dropped it last when it was still over there had dropped it a little bit too low. And we had quite a difficult time getting my fifth wheel under the gooseneck. They didn't put this in there as well. Dropping it a little bit lower, I mean higher, pardon me, than the last people did. Just so that the next person doesn't have that same pain in the butt. So I'm gonna start the engine. This is a gasoline powered motor. Turn the fuel on, so we always turn the fuel off. Turn that on. Now we're gonna drop the airbags on the truck. Let this rest down just a little bit. We should be able to just leave it there. Drop the air in the truck. Wait for the airbags to go down a little bit, cells out. Yeah, and you see in the fifth wheel won't have any problems getting underneath there the next time. This trailer is the way we load it. Is this gooseneck comes right off here. People who, drivers, you guys know what I'm talking about already. I'm talking to the people right now that I've never seen this before. This whole gooseneck right here, it comes right off and it stays on the truck when you're hooked up. So if I was hooked up to here right now, I could detach it from here and put this right down to the ground so that you can drive machinery right up here onto the deck. So you drive it right up the front. This whole thing gets stuck onto the truck.  Today in training, we didn't load anything, but I'm sure that they will be sending me out with this shortly in the next little while or whenever they need something, right? So when that happens, I'll be able to show you guys how we load and unload these trailers. It's pretty cool. It's very different from these tin can aluminum trailers. These trailers mean business. They're heavy duty. And if you didn't watch yesterday's video, you should go back and watch it. In Canada, I know that in the US, you're probably looking at like, what is this? This is what we use in Canada as an over dimension, like oversize load sign. In the US, I believe you have to actually have the words oversize load on a yellow background. In Canada, those work too, but you can also use this. It's your D signs. Means danger, over dimension load. Watch out. This trailer just by itself is over dimension. It's nine feet wide. It's wider than most trailers.  It's been a fun day, a fun morning of training. I'm done all my training. Looking forward to being sent out in 3106. That's the blue truck. This truck is 3,006. That's my unit number, 3006. The blue truck is 3106. Very similar. So 30 odd six, this one. Or 3006, whatever you wanna say. And 3106. I'm looking forward to actually going out in the field to an actual customer and loading up poles and doing some crane work off the truck for an actual customer instead of just here practicing in the yard. We actually haul these Polos all over Manitoba, way up north as well. I know we go to Thompson with them. We go on the ice roads. So I'm gonna be, there's a good chance I'll be doing ice roads this winter. I don't know for sure what they'll need me for, but I'm open to the possibility because I've never done that before yet. And I'd also love the opportunity to show you the viewers here what real ice road trucking is all about. Forget the TV show. Forget that. That's Hollywood. Yeah, they have a producer. They got camera crews. They got medics on scene. Helicopters going around. If anything goes wrong, help is there right away, right? In real life, you're out there on your own or maybe with one other truck. And if something goes wrong, help is hours away if you even got a cell signal where you're at. It's not as glamorous. Some days I'm sure are pretty boring because obviously for the TV show, I'm not knocking the TV show to see it. I'm not knocking it all. It's a great show. I love it. It's a great show. But it's a TV show. It's produced for entertainment purposes. There's all these things that always pop up. There's always some kind of drama on the show, right? Or there's always problems that they gotta deal with. And that's true. There are problems, but when you're out there on your own, it's a little different than when you have a big camera crew following you and a big medical helicopter ready to help at a moment's notice. So when I go up there, what I'm trying to say is it's going to be real ice road trucking that you can watch here. So don't forget to subscribe and stick around because we make videos almost every day here. We're in the heat of summer right now, but winter's coming and that means as ice roads are gonna be opening and you don't wanna miss seeing what it's really like up there.


What's good you too? This is your boy T-World back at y'all again with another art video If you're new to the China go ahead and hit that like button, comment, subscribe Make sure you click post notifications so you will be notified every time your boy drops some heat In today's video, we will be turning Fred Flintstone into biggest smalls to legend You feel me notorious B.I.G. We finna turn Fred Flintstone into him And the program we're using is called clip studio paint if you ain't got it go get it It's pretty dope. It's a program that I'm really starting to like using a lot You know I'm saying So let's go ahead Go ahead jump right into it. We're gonna start out with we're gonna start out with our sketch so I Like to get a pick a light color That's it down some every time you do a sketch. You want to make sure You got it exactly how you like it before you start on the line work.


Hi guys, this is Jason Zach from Nathaniel School of Music. In this guitar lesson, I'm going to introduce you to five really popular and most practiced finger style or finger picking patterns for the acoustic guitar. Now most of these are influenced by not only the guitar, it could be influenced by the banjo, by the mandolin and other folk instruments but generally when you play the guitar with your fingers you're tending to deal with a lot of interesting groovy stuff with a lot of independence. What I mean by that is coming from a piano perspective is you have one ingredient or one part of the hand which will produce something like what the left hand of the piano does while the other ingredients or the other fingers will do or the right hand does something like the bass clef and the treble clef. It's very different than you know just strumming a chord, so the finger patterns can access each individual string and that's pretty much the workflow we are going to follow throughout this lesson.   So this is generally how I am placing my thumb and pretty much all of the work comes from these three fingers, thumb, index, middle. Now what do I do with the other two fingers? Well what I prefer is I prefer to just leave them on the guitar board, on the wood, it provides an additional support and if I ever need to use it for something you know maybe some percussion noise or to mute it then I will bring it into play but otherwise it's pretty much just stationed on the guitar itself just touching because if I keep it in the air I don't know just feels like a little bit of a bad habit sometimes the fingers go up and it doesn't provide that opposing force which you need to kind of secure your hand firm on the instrument. As far as my left hand goes which is the hand which pretty much drives the guitar around to produce melodies, chords and what not, you just learn whatever chords you would normally learn be it C major, G major, D minor, A minor, E minor, F major, G major, C. It's just the right hand or the engine or the rhythm hand which is going to change and that's what I am pretty much going to do in this lesson. We are going to do five approaches for finger style playing and you will have this also ready to download as a notation file with tabs so do consider being a member on our Patreon page patreon.com forward slash Jason Zach there'll also be some of my notes for not only the this lesson but also lessons in the past and which are coming up in the future and do consider being a part of our channel the Nathaniel School of Music channel all you have to do is hit the subscribe button and turn on the bell icon for regular notifications we do quite a few lessons we do lessons on song analysis music theory year training piano guitar bass percussion production and what not so do consider being a part of our channel right so let's get cracking with our finger style guitar patterns first of all just to get our fingers engaged and a very popular pattern which most people start off with even I do this a lot till this day would just be to roll four notes with these three fingers of yours some people may even use their ring I just find that my fingers are a bit too big for the guitar I'm more of a bass player if you if I think about it so how I go about it is play the thumb for the a string C now I'm holding C major chord do with anything but just for the explanation sake I'm just choosing C major so thumb thumb index middle okay C major and slowly but surely try to get the rhythm or the engine pumping and figure out a cyclic effect with your thumb as well just a natural flow or the natural movement of a cycle just to get better and better with it put in some effort and to make it interesting you can do a nice chord pattern with me see gee gee with the base you just fret these two notes that's B open D G D so C major G then D minor you could do minor you need to bring your thumb to the third string from the top the D string which will give you a natural D and you fret these notes with your left hand pinky and index and then a minor okay back to C major you know if you're uncomfortable with four notes you can even do this with three notes you could just do thumb index middle index you can avoid the dub thumb on two notes you can just do you like to move your middle to the E okay so broken up every note is played individually sort of like an arpeggio you could call it okay and another way to maybe take this a bit more forward could be make an elongated pattern double the time of what it is so to do that I'll play it once for you okay so you're creating an eight note plucking arpeggio pattern as opposed to the earlier method which was just four notes now you're trying to take it up to eight one two three four five six seven eight one two three another nice way to count this could be one and two and three and four and one and two and three and four and one and two and okay the second chord and two and three and four and one and two open E or you could fret this and play G so C major G major D minor just to get some chords into the play a minor okay it's back to the progression again C major G major D minor A minor you could do a little A bass D minor D minor G major back to A minor right guys so that was pattern number ones we started with the four note one and play all the four notes or you can play three notes over a four beat cycle if you will one two three four or you could elongate the pattern over an eight beat cycle okay so another thing you could try is something more pop-ish where you could divide the beats irregularly you can do something like one two three one two three one two one two three one two three one two three okay so those that's That's the first line of patterns which basically include playing notes one by one in arpeggio. So these are all arpeggio patterns. Let's now move forward to the next finger style technique. Right, so this one uses a little bit of percussion. You can go. So I'm taking a G major chord this way. G, low bass. So essentially what your thumb does on the guitar is pretty much play chord roots. So if it's G major, it's going to play G, if it's C major, it's going to play C and so on and so forth. So that's what your thumb does while the other two fingers will be playing the remaining notes of the chord. So I have this pattern for you. This is a pattern a lot of people play. Like it's something most people start off with, I guess, on the guitar. So it goes thumb and then play two notes with your index as well as your middle finger. Thumb and then you're getting this double stop thing going so and then you whack the guitar a little bit. Not too hard but just get a nice percussion sound going. Okay, so this is the pattern 1 and 2 and 3 and 4 and 1 and 2 and 3 and few off beats here because I'm dividing the beat into two units.  Just for the last chord you can ignore the and just do what we discussed earlier. Play all the notes one by one, right? For the last chord I'm just sliding my hand from the C major shape just to a nice open D major chord like an add four sound. So G, B, G over B basically then C, add nine, add D. Some reason I like playing D in most of the chords on the guitar so G, D, C.   Or else if you want to divide by three also known as an eighth note triplet where the beat gets divided into three units we can call count it as 1 and 2 and 3 and 4 and 1 and 2 and 3 and 4. So you count it as 1 and 2 and 3 and 4 and 3 and 4 and 4 and 3 and 4 and 4 and 3 and 4 and 4 and 4. So depending on the time field what I call as time field you can divide by two and get this pattern, that's a quaver pattern, a semi quaver pattern or a triplet pattern. So the ingredients are your thumb for the first root of the chord, then the double stop playing two notes of the chord and then of course the whack or the percussion. So this is the second technique for finger style guitar playing, let's now move on to the third. The third technique is what we call as the Travis style picking method and there are two levels to it if you will. The first level is I am just going to demonstrate using the G major chord, so this is how it works in the simple way, so you pluck the outer two notes, that's your root of the chord and the upper structure, the upper note in this case B and then you do the inner one and you could count it as quavars, that's the basic way of doing this. Now you have to move forward in time, so to do that you can either go, that means I am now doing crotchets with my thumb or quarter notes with my thumb, G, G, G or I could even do minims, check that out, the other two fingers are going, while my thumb is going G, G, G or I can even go very lazy, G, G, on the pulse. This is more common, thick pattern it sounds quite good with most chord progressions, most songs, if you want to make this more interesting, we do something like keep this thumb going, the thumb will not change, you are just adding, you start with both the outer notes, G, G, G, if I were to sing just the upper two notes and not the thumb, it can be something like this, that's how it sounds. So practice that over different chords, chords changes are very fast, go back to the easy or the quick change one, the simple Travis pattern, if the chords last bring in the other groove and the thing with finger style playing is you don't have to play all the six strings when you are playing chords, so it offers a nice concept where you could play your chords as either, you know, the index finger playing a note on this string and the pinky playing on the higher string and they are together a minor third apart, P, D, that would also be a minor but you can convert that into major, so when you are playing finger style it may be good to know the minor third which is, will be very close or just one fret away from the root while a major third is two frets away or you skip one and then play the major third, so you can get patterns like this, major, minor, major and of course with the pattern, the more groovy Travis pattern, right guys so that was finger style pattern number three, let's move forward to pattern number four, right so in this melodic approach to finger style playing, you start with a double stop or a group of notes and the top most note will be your melody, so let's say off the top I am playing C major chord and I just keep repeating the C, now this feels a bit boring and not so melodic, so what you could do is move the C to other notes in the scale, so I could do C, B, D, C on the upper strings maybe go to the last, E, D, C and if you climb the guitar with that major third, minor third technique which I told you earlier, very nice melodic stuff almost like a hook which you are creating for a song like for instance this, that's out of the melody, stuff like focus on the upper note, upper register and make that melodic that's basically the other finger style pattern, I have one more for you before we sign off and that is a time signature which needs no introduction, it's the 6-8 rhythm, so it sounds something like this, how do we count this? 1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6, so we could use a very popular pattern of chords used in House of the Rising Sun, A minor, C major, D major I am playing like this, F major, so that's A minor, C major, D major, F, A minor, C major, E, 7th, let's see how that works with 6-8, 1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6, 3, 4, 5, 6, so 1, 2, 3, 4, 5, 6, so to do 6-8 it's almost like the same thing we learned in the beginning but that was over 4-4, so to make it 6-8, 1, 2, 3, 4, 5, 6, you have to come back and you get all these famous songs, let's go back to House of the Rising Sun you could also make it interesting by doing something like this bring in a 16th note there right guys, so those are 5 finger style guitar patterns or approaches or techniques whatever you want to call them I've shown them on slightly different chord progressions but fairly simple chords on the guitar and I hope you can apply it with a variety of music which you play do leave us a comment with what you thought about the lesson and do give us your suggestions in the comments for anything you'd like us to teach you in the future as well and most of these rhythm patterns will be found on our Patreon you could consider heading over to patreon.com the link is in the description and do consider a monthly subscription on that platform you will get content and supplementary material for almost all of our lessons which we have done in the past and will continue to do in the future right guys, thanks a ton for watching, again this is Jason Zach from Nathaniel School of Music, cheers


Does listening to music while studying improve your exam grades? Will listening to Mozart make you a genius? Should you study in silence or with lo-fi hip hop in the background? It seems like there are so many conflicting opinions about what music is best to listen to when studying, but should you even listen to music? And if you do, then what music should you listen to? What is up guys? KarmaMedic here and welcome back to another dose. One of the most common questions I get from my viewers on my long study with me videos is if I listen to music when I'm studying, what music I listen to and if I think it helps me be more productive. I'm always asked this in my Q&A videos and there's even an entire channel on my Patreon Discord server dedicated to chatting about music. Subscribe down below. It seems like everyone, just like me, is looking to find the connection between music and studying. So I did a whole bunch of research and here's what I found. Let's start with one of the things that always comes up when talking about music and studying. The supposed fact that listening to Mozart makes you more intelligent. This is also called the Mozart effect. I found out that this conversation started in 1993 when a psychologist called Francis Rauscher, I hope I'm pronouncing that right, played 10 minutes of Mozart to 36 college students and then immediately followed up that music with a test. The students were also tested in the same way after listening to 10 minutes of someone speaking or after a period of 10 minutes of silence. Once they tested the students with a spatial reasoning test, they found that those who listened to Mozart scored significantly higher on the spatial temporal task. So does this mean that listening to Mozart makes you smarter? Well, no. We can't draw any conclusions about general intelligence and the effect seen from the study were small gains and they didn't last very long. But what the research did find is that listening to Mozart improved spatial reasoning for about 10 minutes. As you can imagine, the findings from this study absolutely blew up. It was everywhere on the news and this even led to expectant mothers playing Mozart for their babies inside the womb. Francis Rauscher even said that they found an entire aisle of Mozart's music in virgin records with quotes from the paper on the adverts. This thing was big and people believed it. It turns out that the study was misinterpreted by the media quite a bit and people falsely believe that you would essentially become smarter just by listening to Mozart. The reality is that this is almost definitely not true and we can pretty much call this one a myth right off the bat. But it did get me thinking, are there optimal types of music that we can listen to when we study or should we just be studying in silence? So the research seems to suggest that studying in silence is a preference and that this might be a good thing to do for tasks that require a particularly high level of focus. But I want to make the argument that music can actually be beneficial if it's something you feel like will work for you during a particular type of study session or something that you just find enjoyable and has worked for you in the past. If you're doing regular revision or going over content, then music can actually help reduce stress at times when the pressure is high. A meta analysis of 51 studies found that music can help to release biochemical stress reducing effects. If you're doing repetitive tasks like organizing your files or creating a revision timetable or anything that doesn't really require that much laser focus, then music can give you a boost of energy to keep you going. You can get a productivity boost from music when you're doing less demanding tasks, especially if you choose songs with no lyrics or something that's less likely to stimulate you outside of what it is that you're focusing on. This could be a song you already know or something that you don't immediately want to get up and dance to. When it comes to cognitively demanding tasks, it's not always the right call to sit in silence and work. This can be a good strategy if you're trying to really focus and you know that you're the type of person that gets easily distracted by music, especially when you're doing a task that becomes intense. On the other hand, if studying in silence sounds awful to you or you can only study when there's music playing, then maybe choosing something that's without lyrics or something that's a bit more repetitive can be the good choice. Lyrics can be really distracting, especially if you're reading words for your studying. It might not be as distracting if you're doing something like solving math equations or physics equations or something like that, but definitely at least personally, if I'm trying to read words and I'm listening to music that has words, then I find it very, very distracting. Soft classical music has shown some promise for demanding tasks in some studies, but I think it really depends on what you like and what works for you personally. This is the key with all of this research. The only way of knowing if these studies will actually be beneficial to you is if you tailor the information that you're getting from them to yourself. If you hate classical music or you hate Mozart, then just don't listen to it. No amount of research is going to make that more beneficial for you, and it's just not going to be as good as listening to something that you like. You're not going to get some version of that famous Mozart effect if you just hate Mozart. If you love listening to Drake, then listen to Drake. If you love listening to Ariana Grande, then listen to Ariana Grande. You might just want to change the songs that you're listening to or the genre of music that you're listening to based on what kind of activity you're doing. Another nice tip is to listen to a song or two before you start work that gets you pumped up for the study session. Make a playlist of all the songs that get you really motivated and throw that on before starting your work. Some studies have shown that music can even improve cognitive performance when it comes to doing creative tasks. The point is that you need to be self-aware enough about what works for you. If music is incredibly distracting to you and you find yourself getting nothing done, then you probably want to stay away from it and keep your high-focused tasks for silent studying or playing something like white noise or brown noise or instrumental music in the background. Whether music actually helps you study is entirely down to the task that you're doing and what music you like and how you work with music. From my personal experience as a brief overview, this is what I would recommend. If you need to be in extreme concentration like you're trying to understand a very complex concept or you're doing research for an essay and it involves a lot of thinking, then for me personally, I just prefer to be in silence or with a pair of noise-canceling headphones over my ears. If you've got a high concentration task like maybe you're reviewing your notes or you're studying for an upcoming exam, you're going through difficult past paper questions, then for me, I like listening to repetitive music without lyrics or lo-fi beats, rainforest sounds, fireplace crackling, or rain, things like that. Once I enter the medium concentration category like reading over lecture slides or going over flashcards, doing past paper questions really quickly, then this is where I feel comfortable listening to music that has lyrics in it. I go somewhere in between. Nothing too crazy, full of rap lyrics and hype, but nothing that's too simple either. And then for low concentration tasks, things like writing emails or organizing things in my room, cleaning up, cooking, showering, whatever, I just throw on Spotify on shuffle and listen to anything that's engaging and stimulating to my brain. I've mentioned that you need to tailor the evidence from the studies to yourself and your personality. And what I mean by this is that if the alternative is to not study at all or do very little studying because the silence is boring to you, then just put music on. It's a no brainer. If you're making a choice between studying at 75% of your maximum efficiency with music or not studying at all, then just choose to study with music at 75%. Getting something done is always going to be better than nothing, especially if the work is piling up. I want to go over a couple of points that I've discovered over my many, many years of studying, which have seemed to help me quite a bit. One, matching the task to the tempo of the music. Sometimes if you're working to a close deadline, it's nice to have a slightly more upbeat music selection in the background so that it feels like the music and yourself are moving at a similar speed. This can be motivating. And as long as the music isn't too distracting, I find that it helps encourage me to stick to the pace that I need to do to reach my deadline. Two, I personally find lo-fi beats or rainforest sounds, fireplace, crackling or rain, anything like that. I find it very, very useful when I'm not in the mood to study. I find that it really helps put me in the zone and increases my productivity and focus. I think the reason for that is that they're quite repetitive sounds and they don't involve any lyrics, they don't involve any words, and so it's just kind of there in the background and helps me focus. But I prefer it to things like white noise or brown noise because that's just like... doesn't work for me. But if it works for you, go for it. And number three is getting your playlists organized. There's nothing worse than trying to study or trying to get into the zone and every couple of minutes having to skip a bunch of songs because you just don't want to listen to them or you hate them. It's the worst. It's also really, really distracting. Especially if you have to use your phone to change that music, then it's really tempting to have a quick look on Instagram or YouTube and you know, before you know it, you've been distracted for 20 minutes. So get your playlist organized and if you have any playlists that you'd like to recommend, please do share them in the comments down below. It turns out that the answer to the question of what you should be listening to when studying is a bit more complicated than I thought, but I'm glad that what already works for me seems to match up with the evidence. If music is not too distracting to you, then tailor the music to the task that you're doing. And if not, ask yourself if working in silence is better for you instead. There's nothing wrong with either ways of studying. You've just got to do what works for you. We've all probably found specific ways of studying that work for us better through trial and error, but I hope this video can help some of you fine tune your studying sessions to make them as productive as possible. And hopefully after this, no one will ask me again if I'm listening to music or not when studying and what I'm listening to. I'll catch you guys in the next one. Check out my Patreon in the description down below. If you haven't already, we do some pretty cool stuff over there. Peace.


My name is Julie Shmura. I'm 11 year survivor of kidney cancer and I was diagnosed with bilateral tumors one in each kidney and I've had three different surgeries. I've had Hand assisted laparoscopic. I've had a cryo surgery and I've had an open surgery Let's see we We host a kidney cancer group in Seattle and we have for the past eight years What else? Well, Julie has quite a story because when she was first diagnosed they spotted the tumor in her one kidney Totally missing the fact that there was a tumor in the other kidney and three different doctors She went for a second opinion and a third opinion three different doctors said what we've got to do is take out your entire right kidney Without ever noticing the left kidney So I guess there's a cautionary tale there that everybody should probably get at least that second opinion and maybe more She kept going until she felt comfortable with the doctor and it turns out the doctor She felt comfortable with is the one that ended up doing all three of her surgeries She isn't a survivor and she's tough But she's been through a lot so We've been to many kidney cancer conferences and you might want to talk about how that worked for hope Well when we went to the first conference I Was totally against it and I really didn't want to go but once I got there I met all these wonderful people with the same cancer that I had and It very it was inspirational and gave me a lot of hope so I came back just Full of joy and happiness and knowing that I was going to live It was great And I think that's kind of the takeaway message that that we've got here the Conferences and the hope that that we got from you working with the kidney cancer Association made a huge difference for both of us As a caregiver, I didn't know how to what to make of it either But in the last 11 years we've become pretty comfortable with understanding what's going on and being able to help other People understand what's going on and to my estimation that has been part of what has made Julie successfully Get through all of the trials and tribulations and all the post surgeries and everything Have any closing Just keep on fighting the fight


Hello and welcome to the Evan Clifton Show presented by Buffalo Wildlings. I'm Greg Royce, showing by Stevenson Tennis Coach Evan Clifton. Coach, you got back last week you went down to Hilton Head for spring break and overall pretty successful trip. Just talk a little bit just the summary, you know, how things went overall. Yeah. Yeah, so I mean it was a great week. You know, it was not just weather wise to get out there and avoid the 30 degree weather and snow that we've been getting here the last few weeks. But you know, we got the practice every day. We played a combined between both teams. Eight matches went six and two. The guys went 4-0 for the week to keep their record a 7-0. And the girls went 2-2 and pulled out two really big wins. So definitely result wise, great week for us. Chemistry wise, fantastic. Our confidence is high. You know, it's it's prepared us for conference play next weekend. We're really ready. Yeah, absolutely. I just first talked about the guys and he said 4-0. You know, really, really on a roll still undefeated on the season. You know, just talk about the confidence they've, you know, where you've had the same lineup now for really a couple years. And that they've really become experienced, you know, college tennis players and that's really starting to show. Yeah. And like you said, that experience is really showing, especially for our seniors who from both teams are really coming up huge for us so far this spring. You know, Doug Vaughn has just been, he's been killing it in singles lineup. He's been perfect at two doubles. Yeah, I mean, for the guys this week was great. You know, it's great to win four matches. You know, obviously you get confidence from winning. But really, we're taking it, you know, the day by day mantra of one match at a time. You know, so our record says 7-0, but really we feel like we've gone 7 days 1-0. And really how we're winning is what is giving us, what gives me the most confidence. You know, just looking at the score lines, you look at seniors like Doug Vaughn and Drew Ryan, those guys. Not like when we win the first set, not only do we not give up the second set and prolong the match, but we're winning the second set, you know, by a wider margin than the first. We're getting stronger as matches go. We're getting more confident as matches go on. You know, that's been a focus of ours all spring is putting teams away, pouring it on guys once we got the lead.  Yeah. Yeah, sometimes that natural tendency is after the win the first set, hey, maybe I'll run off a little bit and know I won 6-2, 6-3, you know, I can go out on the coast and obviously, you know, you can't do that against anybody because anybody's going to come back and get you.  So talk a little about that match and how that went. Yeah. So, yeah, I mean, the week was great for the girls. We went 2-2, all four were very tough matches. We played two teams that were just outside the regional rankings that we knew were going to be tough and we played them hard. You know, we were able to pull out a win at the end of the week against Allegheny and that was huge. They had just beat our defending regular season conference champs, Messiah, the day prior. So we were fired up. We knew they were going to be good. We knew it was going to be a challenge. But we knew just like when we play Messiah and we play our other top teams in the conference, any given day any of us can beat each other. So, you know, we came out there sort of ready to kind of put an exclamation point on the week to end on a high note to get some confidence and the girls really delivered. I mean, from doubles, Nina Bretts and Jackie Nesbeth were down 7-2 or 7-3, three doubles, came back, won four straight games, won that match in the tie break. One doubles was down a break, you know, most of the way, came back, broke at the crucial moments, pulled that match out to give us a lead in the singles. And then Kirsten Davidson played just phenomenal with two singles and won her match in three sets. And then Jackie Nesbeth tied the match up with the straight sets win. And Christina Endi, who really has got her first opportunity to play this year this week. And she came through clutch pulling out that match in three sets to give us a 5-4 win over a team that, like I said, it just beat Messiah the day prior. So we're real happy. Yeah, absolutely. Now your attention shifts, obviously you're not Florida. The weather certainly proves that. Not Florida, but South Carolina. Close enough. It's all warm. But you're back here in the Mid-Atlantic. It's a little chill here. I start conference play this weekend. Saturday you go to Lebanon Valley. A team that both sides is very strong and will certainly be two competitive matches. Yeah, it should be. It's a team we're going to have to beat if we're going to not just make the conference playoffs, but win the conference. And that's our goal in both teams. And so it'll be, it's nice to kind of play them first. We get that measuring stick right away. But ultimately, we know win or lose, it's going to be the second time around that we play them. That's going to matter even more. So we're going to keep, you know, whether we win or lose, we're keeping the same mantra one day at a time, one match at a time, and just getting better every day. Yeah, absolutely.  Yeah, yeah, absolutely. So we're, like I said, Lev Valley Saturday and quick turnaround, Rutgers Camden on Sunday. You know, and whether it's a MAC team or out-of-conference or region team, you know, we're playing ourselves out there. You know, we're just trying to do better than we did the day before. And we feel like if we can keep that focus, that singular focus that, you know, the results will take care of themselves like they have already. Yeah, absolutely. All right, coach, well, thanks for your time. We wish you the best of luck this weekend. And, you know, going forward and now we'll chat again soon. Great. Thank you. All right. For Evan Clifton, I'm Greg Royce. This is been the Evan Clifton Show.