Welcome back to ITW Extra powered by JSA. We are live for day two of ITW 2023 here in National Harbor on the ITW Expo floor. Buffy Herakides of JSA and joining me today is Jonathan Restivo. He is the Chief Development Officer of Cityside Fiber. Welcome to JSA TV. Thank you, pleasure to be here. Yeah, it's so nice to have you here. I mean, it's day two. The floor is already buzzing. The coffee lines are long. We're here live. So this is your first JSA TV interview. So we're honored to have you. Thank you. So welcome. And for those that don't know, can you tell us a little bit more about Cityside Fiber and what makes it so unique? Yeah, absolutely. So Cityside was formed a few years ago in Orange County. We are a fiber developer and new service provider. They're in Orange County, California. The company was really kind of born out of some frustrations that we were having with the development of new technology within the space. And a lot of that was kind of driven by a lack of fiber and inefficiencies around how we deployed those technologies without the fiber, right? And so as we started thinking about ideas for how to better create a more shared infrastructure that was more efficient, more cost effective and that sort of thing, we started Cityside with the idea of establishing a fiber to the home base that would allow us to bring fiber across the city, across a region out into the neighborhoods and that sort of thing. And then we would be able to build and design with more capacity so that all these other use cases around 5G and smart cities, other edge data, enterprise, private networks, all these different types of opportunities that we were seeing challenges with before by building enough capacity through a fiber to the home network, we believe we'll be able to establish more of those technologies and kind of build in a smarter, more efficient way. And so we're excited to launch over the next few months. We are right about to start our first couple of markets in Orange County. Oh, it sounds exciting. Yeah. So you serve both residential and business, correct? Yeah, that's right. We start with the residential side and then we'll have opportunities for small to medium business and then enterprise, tower, tower companies, carriers, other enterprise use cases as well. But our real thing is to try to establish ourselves and establish a real place within the community on the fiber to the home side first with residents, with small to medium businesses. And if we do that well, all the other things, all the other use cases will kind of come over the top of that. And so what our main focus as we establish ourselves within the community is to, you know, one of the things that we wanted to kind of set ourselves apart from the existing providers is to really stress that local presence. We're located in Orange County. We have built there before we've, you know, we live there, our offices are there. We really want to try to establish ourselves as members of the community in multiple ways and kind of hold ourselves accountable as well. Like if you see us in a grocery store, right? And your internet's not working or you had a bad customer experience, right? Like we're right there, you know, to hold ourselves accountable and improve our performance and that sort of thing. So, yeah, being a part of that community was a big deal for us and kind of trying to change the experience from what most people are used to from their typical providers, the legacy providers. So as you enter these new communities, I mean, it sounds like you have a great plan. You know, as a new provider, are there any challenges that you have to overcome? Yeah, absolutely. What's interesting about our market in Orange County is that obviously there are areas that are very high income, high property values, right? But they're being fed by legacy technologies from decades ago. And we kind of asked ourselves why, right? And a lot of the reason for that is because it's really expensive to build and because the cities and the ecosystem for development is challenging, it's very challenging. And so what we try to do at the start is to establish a relationship with the city at the council level, the city manager level, at the staff level and kind of really work with them, find their pain points, find what issues matter to them so that we can address them through that process, right? How do we make permitting easier? How do we work with other companies, other developers that are in the area that we might be able to joint trench or utilize each other's infrastructure? And all of that kind of comes back to the original premise that we had, which was how do we build in a smarter, more efficient way? And just develop this infrastructure better, right? Be more open to a shared infrastructure environment and allow for all those use cases to naturally develop because that fiber is there and because we've worked with the city in a more comprehensive approach, planning, making sure that we're avoiding street moratoriums, making sure that we're designing with enough capacity for the city or other users to make use of that fiber. Well, it sounds like Orange County is lucky to have you. We hope so. Disrupting that community there with new modern infrastructure and technology to scale and grow for generations to come. So congratulations. Thank you. Expect more news, correct? Yeah? Yeah, yeah. We'll have some announcements over the next few weeks and months as we start to launch our markets and our product and our network, which is being established right now. And so it's been a few years in the works to get to this point and we're super excited to be able to bring that to the community. It is super exciting and no better place to talk about it than here at ITW Extra Powered by JSA. Jonathan, thank you so much for joining us today. Where can viewers go to learn more? Yeah, absolutely. So our website is citysidefiber.com. You'll find out a little bit of information about the business and our product lines and where we're going next and we have some exciting things in the works on that front. So yeah, so stay tuned. So stay tuned. And thank you again, viewers, for tuning in to another episode of ITW Extra Powered by JSA live here at ITW 2023. Happy networking.


So, this is the Git and Debian packaging discussion. It's going to be a panel with our distinguished panelists here, Ansgar and Joey and David. But hopefully, it will also be a discussion. So if folks have questions or examples or suggestions, feel free to raise your hand. I'll try to keep an eye on the audience and I can run the mic to you. So, yeah, give these folks a hand. So thanks everybody for showing up. I hope we'll have lots of questions and interaction. I realized in my first buff that if you give me slides, then I go into teaching mode. And that's okay as far as it goes, I like to think, but it's kind of not buff like. So we're slide free. We have Gobi. Hopefully, by this point in DevConf, everybody knows how to, does anybody need the address? It's Gobi.Debian.org. So please join in and edit. Is there anybody who would like to volunteer to take minutes or notes? I mean, everybody is welcome to, but those of us sitting up here might get distracted somehow. Also, while we're asking for volunteers, can we get a volunteer to relay questions from IRC? You do IRC? Thank you. Probably on hashDebconf-talkroom1. So, volunteer for taking notes? It's okay. We don't really need notes. Okay. Notes are for the week. We have the video team. So we'll just watch the video if we want to know what happened in this. So great. So if you're like me, you have no idea really what Git source packages are except that they're not allowed in the archive. And so today, Ansgar showed me how to use a Git source package. And so to sort of underline the fact that this isn't a practical how-to session, we're going to show you how to do this thing which is of no use to you in Debian. All right. Thank you, I think. Okay. So it's a bit of a cheat because we tried this package already and it worked. Oh, no. And I even checked it out. Thanks. Okay. So what do- Check out, check out. It's quite- Git clone, blah, blah, blah. Right. It's okay. Upon your- Okay. Okay. Okay. Joey's more cautious than I am. I just discovered. Okay. So just Deb check out. Nothing fancy here. And that's only because I'm too lazy to remember what the URL is. So this is in the package Perl, one of the package Perl Git repos. I think Ansgar, I hear myself, immortalized. All right. So let us go into this Debian source, Buxy's Magic Directory, and we'll use everybody's second favorite editor. Yes. So as- and in fact, this line of said could sort of sum up my hopes and dreams, which are so far not realized, which is I just want to replace Quilt with Git. Not everybody agrees with that, and that's perfectly okay. It wouldn't be Debian if everybody agreed. Okay. Voila. So commit minus M, convert to 3.0 Git, Nia, FTP masters. Right. Okay. So I was talking yesterday in a bof about recognizing emotions from phone calls. And that's pretty much it. So let's- we're now in the root directory of the package, and we're going to build the package, and we're not going to sign it because, well, we can't upload it anyway, so what would be the point? Okay. There's some noise. I mean helpful messages. Stop yell if I'm going too fast. I mean nothing too interesting is happening so far. So what did I do so far? I edited format, and then I just ran dpackage build package as normal, dpackage source directly would work fine. So let's have a look at the DSC file, blah, blah, blah, and it has only one file in it, which is a Git bundle. So some of the noise that rattled pie was something about being a native package, and so from dpackage to this point of view, these things are kind of native because there's no separate pristine tar ball. Let's change somewhere else. It's gone. Right. TempFS. Let's have that TempFS discussion. Right. So I could actually just directly clone. That's just a Git bundle, but let's try and use the more debian-y tools, dpackage source minus x. Thank you, ZSH. Okay. So what happened? Dpackage source knows how to unpack these things, and it basically just does a Git clone. And well, it looks suspiciously like what I started out with. So cp minus a might have been a simpler way to do this. You do have the option of giving some Git shallow options to dpackage source to reduce the amount of history that's included. But if we look at the, okay, so let's look at what branches included. So just the master branch. And if we look at the tags, hey. Quick question, David. Yes. Just to get the context, you're syncing against which repository? So you mean what is origin here? Yes. Origin is the Git bundle. So origin is actually the source package here, and pushing back to it isn't going to do us a lot of work good. But, so Git bundles look just like repositories to Git. You can clone from them. Okay. So how did we get the Git bundle? You use the Git bundle command. It was dpackage source just runs that to build the bundle, which is effectively the same as a Git pack file with a few header information. Could you show the source directory? Just about one level up that was created. You want the source directory where I made the, okay. Yeah. With the long listing. All right. So this is a regular Debian packaging directory that happens to be in a Git repository. And if we look at Debian source format, it says 3.0 Git. And so when I said dpackage, build package, I could probably say dpackage source, right? Let's dash b minus uc minus us. All right. So this is just calling dpackage source as we might in any other package. And then the reason I didn't do that before is because you have to be in the parent directory or something. Right? And I'm only doing the building the source package here because mainly that's the part we're interested in. Also, I don't have the dependencies to build dependencies. Okay. So what just happened? So you saw some of the things, delta, blah, blah, blah, that's Git talking to us as it makes the bundle. Why don't you scroll up just a little bit? If only I knew how to do that. Shift page up. Shift page up. Thank you. All right. Okay. So here we are. Right? Info bundling dash all, counting objects, delta compression, the usual sort of stuff that Git mutters about while it's working. And then, oh, apparently I'm using xz compression. That's nscar at work, I bet. There's nothing to do with Git, the fact that it's using xz compression. So can you show the files in the parent directory? Yeah. Okay. As usual, dpackage build package, put the source package in the parent directory. And we have a dsc and a .git. That's a .git file, not a .git directory. Right. And so here's the dsc file. We see right at the top, it says 3.0 Git. And then everything else is as per normal. And then down, it has a package list. And only in the checksum section do we see that there's only this .git file included. So, okay, so that... Can you show us the actual Git bundle? What is it? Is it a text file? Is it a binary file? It's a binary file. So I could... Don't know how to... I can basically show it to you by cloning it. Right. Okay. Any other tools apart from Git who read the Git bundles? If you look at the format of a Git bundle, like I said, it's the same as a Git pack file. There's several programs that can read Git pack files. They're all various implementations of Git. And it is a documented standard file format with version numbers and all that kind of thing. The Git bundle adds a small header saying it's a bundle and a few other pieces of metadata. Question? So that's pretty much it for the demo. We can... Like I say, now when you unpack... I mean, when you unpack a source file, you don't really care anymore, right? You have the directory. You have the working directory. In this case, you also have the Git history, which I guess we'll discuss in a minute. That's actually the main weakness of this format as well, is that we really have the complete history here. So I don't know if that's readable, but you get the idea that no FTP master, even Ansgar, who sort of likes Git, is going to be willing to review that. And this is actually not a huge history. It has a thousand... I don't know if you were counting, but there's a thousand commits there, which is a smallish Git history. I mean, so I think plenty of projects in Debian have in the range of 30,000, 100,000 commits in their history. So clearly something... Well, clearly looking at every one of those commits is not viable. I have a question. What makes the magic prompt that tells you which bit you're in that looks really useful? Yes. So that's actually... It is very useful. It is ZSH, and I think I stole this from Martin Kraft originally. So it's one of those... Yeah, it's more or less off the shelf ZSH, but it still seems to take some configuration, but it's not that hard. Question up front? Question regarding the Git bundle format. Does that encode any sort of references to external repositories? This kind of leads into the next question about shallow branching. As far as I know, it does not. I have to admit that I don't fully understand the Git pack format, but as far as I know Git packs don't do that, and Git bundle only adds some refs that are included in the bundle. So when you unpack it, it knows what refs to create. Right. So I mean, obviously the ideal would be if there are concerns about not having the whole history in the bundle because of having to review everything, then the ideal would be you just have the tip and you include something that actually points you to the right place for all the history, or two multiple right places for all the history. My incomplete understanding is that this is essentially an upstream missing feature in Git, is that shallow clones are not as nice as they could be or should be. Any other? Okay. So I think that Ian. So the reason we're using shallow clones is because we don't want the entire history in the archive because the FTB masters don't like it. However, we already have in general complete history on Allioff, where apparently Allioff admins are completely happy with it. Is there anything stopping us from somehow treating the archive as a output format, output location and not having to have all this pay? So you might be jumping ahead to line nine, which is totally fine. Oh, you want to answer? I mean, I'm not quite sure what you meant by treating the archive as an output format, but I think that you have a good point about Allioff already having, you know, generally the full history, upstream history of every Git repository that we pulled in. And there probably could be licensing issues with what's on Allioff. I think it's just that we're not shipping it to quite the same degree that we are. And the FTB masters are, I'm sorry, I don't think we're shipping it quite to the same degree that we do ship Debian source packages. So that might be the only dividing line. Well, Allioff can also. Well, we don't just bring us between main and contribe on Allioff. So when there's not free but distributable files, I think that would be okay to have on Allioff, but it should not be in the main archive. I guess I could mention since the FTB masters did bring up this, you know, concern, which I hadn't really thought about. Currently, my best approach to trying to deal with this, which I haven't tried to implement yet, is to instead of just having a shallow clone that say has, you know, the most recent commit or something, you can make a series of branches, basically, each of which has a Debian release. So you can have the last 10 releases or something like that. And you'll have, you know, you'll have a snapshot of each of those available in your Git repository in the bundle. And then if you need to deepen that, you can pull from Alioff or something. But that's not implemented. I think it's probably the blocker, as far as I'm concerned, for getting this in. I don't know about the FTB masters. Is there a pristine tar integration? And can I regenerate the upstream tar ball from the Git bundle? Maybe I could answer that. It's just another Git repo, so sure. Anything you can do with a Git repo, you can do with this thing. On the other hand, the reason, think about why do we have these upstream tar balls and why do we use them. It's to verify what we got from upstream. In the case of a lot of these Git repositories, what you get from upstream is a Git repository with, if you're lucky, some signed tags on it. And so that's a major reason to want to use this format in the first place. And you won't have a pristine tar ball. Yeah, I understand. Because for me, it's not necessarily that the developer can get the original tar ball, but that you can actually get it from the Git source package, from the Git bundle. Because one nice property of the Debian mirrors is that it's mirroring upstream software and upstream tar ball releases across the world. Where they do exist, and they're becoming much less frequent if you look at, say, Rails stuff, or, you know. That, of course, one can question the sanity of some. Anyway, never mind. No, I can't hear me. I was going to say, there's sort of two things going on here. One is this notion that as more and more upstreams move to rational, distributed, revision control systems like Git for doing their base work, then the nature of the problem we're trying to solve changes. And that's certainly true. I believe today that in my own set of Debian packages, a very small percentage of the upstreams actually themselves use Git. And I don't always even notice when they change to it. And then there's the whole kerfluffle about figuring out what to do, how to re-synchronize my work with theirs and all of that sort of thing. But it also strikes me that we've had this mechanism for a while for capturing VCS entries and control files. And some combination of capturing information there and what we actually have to put in the file. It just seems logically like it ought to be possible to come up with some suitable, as Joe was saying, maybe it's where we actually do the Debian package building on specific branches for each Debian release or something. I don't know, it seems to me like we ought to build a dream up something that resolves this in a plausible way where the rest of the package contains the pointers to where to get the rest of the history. So one thing that occurred to me in response to Dmitri's question about pristine tar balls and Debian being a kind of librarian for the free software world, which is certainly a positive thing that we do. But I mean in a purely technical sense, we could do that by signing tags as well as by making tar balls. And for us, when the tar ball isn't used in the build process, it seems a bit artificial to declare, hey, this is our pristine. We're gonna get archive to a tar ball and then put that tar ball back into the same Git repo. I don't know, without getting into weak hashes yet.  However, one of the things that seems to be falling by the wayside, and this was a point that I heard Ian making in the Hack Lab the other day where he was trying to check out a package Git tree and get it to build. And he was running into problems because there was no release machinery in that Git repository that would actually give you the auto conf output and have something you could actually build as a package. Because you had the source, which consisted of what upstream considered the source that was checked into Git, plus the Debian directory, and all the auto-generated files were missing, which traditionally we view that as, yes, you don't check in things to the repository that are auto-generated, but if you want a representation of an actual buildable Debian source package, you actually should have those in there. So are there any conventions developing around that in your work? And I'm actually interested in this question in terms of larger usage of Git build package as well, to make sure that when people actually are checking out things that are Git, there is some obvious consistent way to build the package. So are you answering Steve's question? Yeah, I was going to say, for me, the simple answer is to always have the Debian packaging do the bootstrapping work and build depend on whatever auto-star, et cetera, tools are required to do that. I've actually been doing that by adding another target to my Debian rules files, which is the configure target, and other folks I've seen are doing the same thing, and this sort of insulates you from all that, and it sort of guarantees that when you do a clean, you actually flush away all those auto-generated things, and when you do the build process and sit, it depends on the configure having completed and generated a stamp, then you kind of get that whole bootstrapping thing captured there, even if it's not captured by the upstream folks in their sources. Yeah, I guess there are people sort of for and against auto-reconfing, and I guess the one point of view, which was sort of diverging from the topic, but it's somehow related to, as you mentioned, because it comes up more often in building from version control. So the one point of view is you introduce variation into the build process when you don't ship configure exactly as generated by auto-conf version zero that upstream is using or whatever. I... Ian has a question for it. I have an answer to this, which is, we don't need to have one answer to the question of should you do this, and we're never going to get one answer to that anyway. What we need is either for the thing that you get by checking out to have all of those files in it so that they're pre-generated and they're not regenerated when you build the package, or the rules file does it for you. And either of those is sufficient. So Ian, but is this a question for Demian Packagers or is it a question for upstreams or both? Yes, but upstreams seem to be doing all sorts of crazy stuff. And different ideas about these things. We at the very least have the benefit of being able to declare a standard interface to a package. The moment we don't have a spec for what it means to be a standard Debian package in version control. So it's not possible to get a package from something that you expect to be a version controlled Debian package and build it because you might have to run some weird script, it might be on a weird branch, there's all sorts of strange things that aren't sorted out. So this is actually the last item and I don't care about the order. I'm glad you asked these questions because I had no idea what the point of this item was in the agenda. So some people are using readme.source for this kind of thing, although it's technically not what it's for. Okay, so I can relay Vdale's comment there, which is that that's a terrible idea. So do we need a readme....? No, it needs to be automatic! Okay, yeah, that seems reasonable enough. Yeah, I was thinking you had it right. Either the source package when unpacked is ready to go or the rules file does the bootstrap and text query. For a 3.0 git package, this would be the case because basically what you get from the checkout is what the buildDemons, for example, will use to build the package. So it will either have to have the configure files or rebuild them at the time. So to the best of our knowledge, there's not currently a DH1 build system that recognizes how to do the right thing, which might be a good idea for facilitating Debian rules doing the right thing for a majority of packages that are in this scenario. You mean for configure files? I mean that DH should know how to run... The DH auto underscore configure should recognize a git tree that has no... That has, for instance, a configure.ac but doesn't have any of the... It doesn't have a generated configure script or whatever and should know to do the right thing so that people aren't once again in the situation of putting lots of readily-automatable build logic into their Debian rules. It's not in debhelper, per se, but I think that DH auto-recomp or something like that does do this. It's a sequence add-on, so it's one with auto-comp or something like that in your rules file. It seems relatively clean, although a little messy under the hood. So I just wanted to comment that I'm a huge fan of the not shipping all the auto foo in the package because it just means you get ancient versions of auto foo which have all piles of bugs. We fix a lot more bugs by redoing it than we do by keeping the old version even though that's kind of how the auto stuff was designed. I think it's a bad plan, so this is just great. So more discussion about... Yes? Yeah, I was just going to say that I had all kinds of trouble for a long time with Emacs and that sort of thing, and things got much better when I switched to not... Can you speak up? Sorry. In Emacs, I had all kinds of trouble with that kind of thing for a long time, and things got much better when I switched to not shipping any of the pre-built auto foo files. And to your earlier point, in DH, I just create one line override for I think it was DH auto-configure or whatever, which invokes either auto-regen or auto-recon for whichever one's appropriate. So... Any more discussion about shallow histories and what... I mean, so one thing we didn't talk about, which some people I know feel very strongly about, so I'm a bit surprised there's been no yelling, is that... Well, Dimitri sort of mentioned it obliquely, which is that, okay, this thing you handed me, which you told me was a source package, I need Git to read it. And for some people, that is much, much worse than needing tar and deep package dev to... Well, to read it. So I don't really feel that way myself, but I want to sort of throw that out there because I know... I've been yelled at that way before, so... Anybody here want to take that point of view or expand on it? Well, I have in the past downloaded Debian source packages with current... You're really yelling very quietly. Okay, how about this? Better. I really did download packages from Debian Archive on Solaris machines and then trying to build them because that was the only way to get a package and I knew how to build a Debian package quickly and get all the correct dependencies. So I did use it on a non-Debian machine just purely as a source repository. I mean, Git runs on Windows, so... Well, true. But not on Solaris 7 or whatever it was. Okay, so you're saying it would be a restriction? Yeah. I can agree with that. I would say that another possible devil's advocate reason to worry about this is what if in 10 years we're not using Git anymore and we have all these Git source packages? Could happen. I think that it can be managed. So firstly, I'll just come back to the point there about Solaris. I don't think that we should take that as one of our goals and Debian format source packages have never been intended to be unpickable on anything other than Debian. The real reason to be wary of Git format source packages is that the Git user interface is a catastrophic disaster, at least for some people. And it's not so much that you have to install some tool. You always have to install some tool. The problem is that you might have to use it. All of that can be buried in something. It means that you don't need to understand how it works. You don't need to understand its data model and so on. Then I think a lot of that objection would go away.   That might have been the most important part of my demo then. Steve has a question. Well, it's not so much a question as, I guess, a follow-up comment that... So, for instance, the 3.0 quilt format is handled internally by dpackage. And I guess I'm surprised that this is something we're going back and forth on because I would expect that if this is something we're going to use in the archive that dpackage itself would implement that in some capacity without relying on external tools. Because you don't want... I would expect... I don't know. That's really a question for the dpackage maintainers about how they would choose to implement that. But certainly you wouldn't want dpackage-dev to not, upon installation, give you everything you need to work with any source package in the archive. So whether that's dependency on Git that it shells out to or some sort of internal re-implementation of Git, I would expect it to be transparent to the user that dpackage-dev is the interface you need to worry about. And that's it. Sure. As I say, I'm Devil's Advocating and no, I think the point really was about use outside Debian. So if you don't care about that, then we can move on from that point. Are there really no questions from IRC or rude remarks or songs? Okay, funny jokes? Okay. Regarding the non-Debian users who may... I mean, by GPL license, they should be able to get the source in an easy way. I don't think Git is an easy way for non-unix platforms, even though it's possible to get Git on Windows, I agree. For instance, if you ever had to get PDF or some documentation or some funds from Microsoft, and I probably... I guess you would have been very upset to have to get some strange MSI file or CAB file to get your PDF for you. So I don't think we should... We should make it easy for non-Debian users to get the source of our packages. It doesn't mean... It could be HTTP with something... Sure. I mean, I guess this is the argument, and Ian doesn't care. He's maybe going to tell us so. And I think we have git.debian.org to also make that access available as well. Right. So the argument being made there was, as far as I can make out, partially based on licensing. And I don't think you could make a plausible argument that almost whatever format Debian chose to use was not a format conventionally used for software interchange. So essentially, whatever format we use will satisfy the legal requirements. That's not the issue. The issue is, do we think this is an important thing that we're supposed to be doing or should we try to make our own workflow smoother? And at the moment what we have is we do have a version control system. Debian Archive is a version control system. That's how we use it. It keeps multiple versions of things. You can commit to it by uploading, all that other kind of thing. And it's a catastrophically awful version control system. It's really absolutely terrible. I prefer it to SVN. I'm kidding. I'm kidding. I've never used SVN. I think that's entirely plausible. But really, in this day and age, there's so many better tools available. And we are making our lives extremely difficult by battling with these terrible tools where it takes you, sometimes it can take you half an hour, an hour, to get from, I've got the name of a package to now I've got it building and I just want to make my change.  When people outside our crazy bubble, these are trivial operations that take minutes. We're wasting so much time. Okay. Well, I think we have more comments along those lines. Oh, a question from IRC, maybe? Yes, there was an opinion brought up by Bernhard Link. He said, well, Davion is not only about participating in free software, so we should care that other Linux distributions are able to see what we do. Sure. It's a comment, and I agree with that sentiment. I don't think anybody here thinks we should somehow make it harder on purpose. On the other hand, I'm a little skeptical of this argument that there are Linux distributions that can't use Git, and if so, I pity them. I mean, okay, I know that Git is not everybody's favorite tool and that it's far from perfect, but on the other hand, it's becoming kind of basic literacy in my... And I know people who dislike Git find that even more upsetting that Git is becoming a de facto standard and you kind of can't work in free software. I know people that this drives literally irrationally angry, but there it is.  Anyway, it's not... I felt like we should bring this up. Maybe we have five, seven minutes left, so I don't know what you guys want to talk about for this. There is another opinion from IC, from the same guy that is trying to look for patches in other distributions and to have to use different VCSs and different branch naming setups is quite a hell. Yes. Right, so I really sympathize with Git haters whenever I have to use BZR or HD or SVN, right? I mean, it's mostly familiarity. Hello. I know you probably have seen me around. I'm from Canaima distribution. We kind of have said Git as a default for our packaging in Canaima. All our packages are tracked by Git, so we benefit from it in a great way. We simplified the way we make change logs with GitDZH. We also participate or contribute, or help contribute to Canaima by basically showing the things we do with the commit diff. I just want to say that it's a magnificent tool, and we have that experience in Canaima. So I'm happy to keep discussing or I can do another demo. What do you want? Discussion is somehow more valuable, I guess. So I'd like to go on record as one of the Git haters. I really do think that the Free Software Community has missed out on an opportunity to standardize around VCS with a much better UI, that being bizarre. But given the fact that everybody has a standardized around Git, because it happened to have the right advantages at the right point in history, I don't have a problem with there being a Git source package format in Debian, and the reason for that is very simple. It doesn't matter. The interface as a Debian developer, if I'm going to be working on somebody's package, the interface that I'm going to be using is the same. I'm going to be using dPackage. The fact that there's additional information there that happens to tie into the version control system that the maintainer would be using whether they have this package format available to them or not is immaterial to the kinds of interactions that I as an NMU-er would have to have with that package. And as long as that's the case, I'm happy for there to exist a 3.0 Git format. Actually, I think I had forces Git on you a bit because you have to commit your changes with Git. Well, except that dPackage, buildPackage, or source or whatever now has a dash-dash commit. So you use that as a version control system, abstracting over this anyway. And I think Ian had a really good point about it, being a horrible, horrible version control system, but it is the one that you use if you don't want to dive into the details. Right. So I think Steve's hit the nail on the head. There will always be people who don't want to use a new tool. And in an organization the size of Debian, we're not going to be able to just say, if you would even switch over to some new workflow. Those of us who have tried the new workflows and have rotated our brains at 90 degrees to reality to cope with the Git user interface now find that those new workflows are much better. So what I want is I want to be able to have a Git workflow and I want Steve to be able to have his dPackage workflow. And if he wants to spend half an hour wrestling with dPackage when I'm typing Git clone and commit and push, that's absolutely fine by me. And what we need is a set of tools that means that both of us can get what we want in a standard way without having to run bizarre scripts, not know where to find the source code. It should all be automatic, standardized, and none of us should have to do extra scutwork the computer should be doing for us. And at the moment, I think unfortunately, our tooling is considerably short of that. For example, we're going to have to have build the source package from a Git push, which we don't have and that's a bit of a political problem as well, but it is an important thing that will need to be fixed. And until we fix that, you're missing half of the workflow. One thing I've noticed a lot more recently since the 3.0 format is things that you can't build twice. And I don't know whether heading in this direction is going to make that problem much worse. One of my packages doesn't, and I'm not quite sure what to do about it because it's tech craziness. Something definitely we should worry about is files that get changed by the build in place, and then it all goes wrong. Don't build in place? How do you make tech not build in place with the source files? Can you do that? That's just an example. Okay, so we're veering off, and I think we have like zero minutes left. We could probably sneak one more question in without further angering the video team. Who wants the last question, who's not sitting in the front row? Another question from ISE. Jaroslav asks about, is it preferable to carry pure Debian Git repositories, i.e. imported top horse and Debian on top, or maybe original upstream repository plus Debian branch? Can you repeat the question? Whether it is preferable to carry pure Debian Git repositories, i.e. imported top horse plus the Debian sub-director on top of that, or maybe original upstream repositories plus a Debian branch? I don't know what's preferable. I myself do both. I find the second option, if you don't care about resource consumption, is probably the good one, but someone... So cherry picking upstream patches with Git is great, and I think that that is so, and if that costs 100 megs of disk space, I'm okay with that, but the Ali auth admins aren't here, so it's safe to say that. I guess we should stop. Thanks, everybody. That was a really great lots of interaction, and that was... that's what you want for a bof, and no anger. Well, Steve's a little bit angry about the fact that BZR lost, but it's okay. Okay. Thank you.


So thank you very much. Yeah, so with my topic being how the and I think we're gonna have some slides my topic being how the excessive how excessive wealth disorder hurts the environment. I have 60 slides in seven minutes So, um, let's see how that goes. And so the first slide I guess do I do it do I advance them or do I tell you? pardon Do I advance the slides myself or do I tell you when to advance? I'm sorry Okay, is there a is there a clicker somewhere? Sorry. Okay, sorry. Okay. Thanks. Okay, so Thank you, so I hopefully Thank you so So to quote the spider-man's uncle Ben with great power comes great responsibility and we know that different folks with wealth have Different ways of interpreting that some do the right thing like a couple of people who are in the room and others Who use their wealth in in responsible ways and our what was the phrase that was used by Barbara wealth? Traders Class traders, thank you and others not so much. And so we know how this really has We're pretty dire impacts on the environment in terms of some folks who are dominating. Thank you dominating our Economy and our political our political systems and so there's these are five facts That hopefully I can be from here that are linking wealth inequality with the environment before by these Dario Kenner and Richard drier So the richest 10% spend more including on indicators of the ecological footprint including fuel for private jets as was said before And or meat and other things That on average support for a strong environmental policies is higher in countries where inequality is lower That inequality is a strong indicator a driver of consumption including the consumption of the wealthy but also through status envy and where people are trying to catch up and that the Well held by the world 782 high net worth individuals alone could provide over half of the world Population with access to 100% renewable energy by 2030 if we were able to redirect that well And just as a note in and many of the privatization scenarios What is it happening in terms of how wealth is being directed is that the primary goal isn't to meet energy Water food housing or criminal justice needs it is to make as much money as possible on the commodities of energy food water Housing and incarcerated persons as I'll illustrate as we go forward And so this is basically 10 illustrative scenarios and hopefully you can I'm talking like an auctioneer, but again seven minutes How well how an unequal wealth and power are destroying the environment and so first looking at a historical context looking images from the trail of tears to the to the reckless extraction of natural resources to this being the 400th anniversary of the transatlantic slave trade we have this history of rampant and commoditization violent extraction and exploitation of human and natural resources and all this is institutionalized in our trade policies our manufacturing policies and so forth and so on and so with our energy systems we put out a report this year in April 1st called fossil fuel foolery and Illustrated a primer on the top-ten manipulation tactics of the fossil fuel industry and just to show you a few we have the investment in efforts that undermine democracy that is put forth by the industry we have The financing of sorry can you go back? Oh, sorry you're gonna miss that one anyway the financing of political campaigns We have the funding of scientists and scientific institutions to public bias research studies Let's say basically the climate change doesn't exist. We have. Oh, thank you Okay, maybe maybe you can go back again. Sorry violence financing of political campaigns again Okay, so financing of political campaigns and pressuring politicians which we've spoken about and then we have the contending that government government regulations hurt the economy ratepayers and poor people and so The ways that people have put this across have been very Unfortunately successful in so many ways and it's to the detriment of the economy and of our human rights Then we have denying or understanding the harms that polluting facilities cause to the people in the environment And if you can see the tagline here first, we have to convince the people that good health isn't everything so these are the kinds of Messages that we that are kind of the undercurrents of what we hear every day Deflecting responsibility and shifting blames to the very communities that that they pollute I can't tell you how many times I've heard from these polluting folks like oh they moved here Like we were just minding our own business and then this community member moved into you know into our cloud of pollution and and then pacifying co-opting and Misrepresenting communities and organizations trying to buy folks off trying to to fool folks into supporting Supporting people supporting this agenda and being the weapons of our own destruction And then praising false solutions and denouncing real solutions I never thought I'd be quoting Arnold Schwarzenegger, but I equally await the administration's regulations protecting pagers fax machines and blockbuster He said in response to Trump administration Trying to support the brain coal back and so and then yeah, so all the different ways we do that And so just a few energy inequality by the numbers $6 trillion is the amount of our of our energy economy $9.8 million is the average compensation for for for coal company CEOs 38 that 33,840 dollars is the average amount that workers make and a bonus statistic there is that on average the CEOs compensation is 289 times the rate of the average average worker and another bonus Is that two billion dollars is the amount between? 2000 and 2016 that these companies spent on anti regulatory anti clean energy Lobbying 41 billion dollars is how much african-americans spend on energy every year 1.1% is the amount of the number the percentage of african-americans who are working in the energy sector and less than 0.1% is The amount of revenue the african-americans gain from the energy sector and then five dollars is another bonus statistic Is the average wealth of a black woman and so this really kind of paints a picture of like just a sheer impacts of Or the numbers of energy inequality and then how that actually plays out is another I'll talk a little bit more in these illustrative scenarios And so as we know this kind of agenda protecting that level of wealth Plays out in how we're seeing these kind of images and these kind of policy making in terms of rolling back Regulations to protect that that wealth and keep that wealth quite centralized So we put out reports like fumes across the fence line that really show that communities of color low-income communities are always tend to be on the on the front lines of the impacts of the fossil fuel industry cold-blooded putting profits before people also pointing out that 78% of african-americans live within 30 miles of a coal-fired power plant african-american children are three to five times more likely to enter in the hospital from an asthma attack and two To three times more likely to die of an asthma attack And so these are the types of ways that people are more exposed to the pollution that comes from this these money-making Industries in the way they're doing their their money making this is on the lower left hand is the seizure Chavez high school Which is in Houston, Texas? Which in the oil refinery behind it is one of five oil refiners within a 10 mile radius of that school because they have This pro-business policy that has no zoning which means that you have this kind of Zoning of a school right on top of a polluting oil refinery and the upper right-hand corner We have coal miners 76,000 coal miners have died of black lung disease since 1968 while the National Mining Association That represents their very employers have fought against the regulation that would have protected them from from coal mine dust Meanwhile, they're fighting in the courts They've actually employed folks from places like Hopkins to say in court that when when people come in and Are seeking benefits for black lung they will say oh well, that's not black lung That's tuberculosis like this mad rash of tuberculosis among minors and in order to refuse families benefits So this is just more of kind of the same. This is a family in in the Four-corner's region and the coal-fired power plant behind them is one of four coal-fired power plants within a 30 mile Radio 30 mile radius of where they live But yet though they have the two coolers on the porch because they like 70% of the people on these Navajo lands do not have Electricity or even running water. So this is really just the height of inequality all of that electricity that's generated by those coal plants goes to power Las Vegas, Los Angeles and and Phoenix and and doesn't even go to the places who are The communities that are bearing the brunt of the expert Journalities from those report those on those emissions like asthma like COPD like the birth defects that I don't know if you notice So one of the person's picture there was pregnant that the person might be facing and so oops Sorry, can we go back to other slides? Sorry about that the other side is a report We put out last year called lights out in the cold reforming utilities shut off policies as if human rights matter And in that report we profiled a number of families individuals who have actually paid the price of poverty with their lives when their electricity is cut off and they use candles to light their home and the candles end up burning down their home when they Electricity get when their power their oil and gaskets cut off and they use space heaters to to heat their home and then we know space heaters are the number one cause of of Home fires and then this person just last summer a grandmother who had just paid and Was having a hard time paid and her spaying and her son paid $200 on the bill But it didn't catch up in the system quickly enough and they caught off her electricity And she was dependent on a respirator and that respirator of course was run by electricity and so she died So literally paying the price of property with her lives But meanwhile people are making nine point eight million dollars a year and in compensation So my time is very much up and I'd have like 30 months. Okay. Good. Can I have a little okay? Yeah, all right two more minutes. Awesome. So I'll talk even faster So with our food systems when you talk about big egg We have the terminator seeds which again going against the very laws of nature the regenerative notion of nature of of nature which Which is these terminator seeds would then go on which blow over into farmers lands and they're kind of they have this kind of Vival impact on farmers and Vandana Shiva has done a lot of work on the the proliferation of Suicide now amongst farmers because of the impact of some of these big egg practices We also know the commercial animal feeding operations while amassing money for for these agricultural with for these companies that are Making money off of meat are then harming the not only the animals in terms of the inhumane conditions that they're working in but also the the the The health impacts whether it's the methane that's being emitted driving climate change or the communities that living adjacent to these situations and then and then again with the people being more likely to access the negative impacts of the Food production also less likely to actually access Healthy and nutritious foods they they talk about communities being food deserts But the communities that are in those conditions don't actually like to term food deserts because deserts are implied something that happens Naturally, and they know that whether it's redlining or gentrification and displacement or all these different ways that they're Intentionally separated from resources so they prefer terms like food apartheid and so forth that actually name what's actually going on One of my friends who lives in the DC area who's a white American? She can't she told me that her son came home from school one day And he said mom why are all the black kids rich and she's like what makes you think that Milo and he said well You know I just have carrots and celery in my lunch And they have Doritos and Cheetos and take Keto's and so I'm like there's so much wrong with that statement But we but we both kind of analyzed because she's a labor organizer as well And just analyze what that actually what all went into that comment and so we talk about our water systems We all know that the trifecta of the Flint water crisis wasn't just about poison water. It was about water that was poisoned by legacy Legacy pollution from industry that was unregulated because of the influence of pollute of these polluters over our political economy And then the disinvestment once once Flint kind of had worn out its usefulness to these communities that pulled out on mass and And pulled out hundreds of thousands of jobs from Flint that left it in the situation where they where they were vulnerable to having their Democracy displace and we see that kind of that kind of situation that kind of plays out time and time again Like the red dog mine in the Alaska area Which has violated the clean out of clean water acts 600 times and yet it continues to operate And yet we have people who again get caught off from electricity because they lose a couple of Payments so again, I could go on and on because there's about 20 sides left But just to wrap up because our time is short just that these are just a couple of more talking about Halliburton that actually sought an exemption from the Safe Drinking Water Act The notion that someone can even apply for an exemption from the Safe Drinking Water Act Let's us know what's wrong with our political system and of itself and so in the end we talk about some of the other Disparities in the ways that the companies all sway over that that are driving the the climate crisis Which again, hopefully you'll have access to this you can see some of this yourself But in the very last slide is oh well before that This just one quote and when we talk about the US being 4% of the global population But 25% of the emissions of drive climate change and yet we have these punitive migration immigration policies And this is a quote from war sign sure a Kenyan born Somali poet You have to understand that no one puts their children in a boat unless the water is safer than the land So these are just 10 policy solutions that I put forward and of course the last one is tech techs the super wealthy And that's my contact information. Thank you


On Tuesday, we found out that the U.S. home sales dropped by the most nearly four and a half years in March. The U.K. employment growth slowed in March, but the German zoo survey showed that the mood among German investors improved in April. As concerns about the impact of the coronavirus pandemic on Europe's largest economy seem to have eased. Welcome to the Tick-Mill Update. I'm Canada Niel, the founder of the Investiva Movement. Make sure to subscribe to the Tick-Mill YouTube channel and support us by liking and sharing this video with your forex trading friends. On Wednesday, we'll be looking at the U.K. and Canada's CPI numbers. Today I'm looking at the Euro-Yan pair, which has not been able to break below the key support level of 117 after days of consolidation. With the support hold strong, this could turn into a double bottom bullish reversal chart pattern bringing the pair back up to as high as 121. However, if the bears finally win the battle, doors will open before their drops towards the lows of 2016 at 111. We are still in the wait-and-see mode, eyeing the confirmation of either direction. Which direction do you think the pair will break out? Head over to the comments section and let me know. Of course, trading in the financial markets involves a risk of loss and it should only trade the money that you can afford to lose. If you liked this video, give it a thumbs up, subscribe to the Tick-Mill YouTube channel and I'll get back to you with more updates tomorrow.