 They're programmed in CSH. It's not like ZSH at all. And they say it's called C-Shell because it's supposed to be more C-Lite. But that's a lie. Alright. The other thing I want to try and get done in the next year is an optional tree structure. This will require us to write a bunch of policy first and get that built out. But basically it would be using opt-epil. Opt-epil bin, opt-epil live, opt-epil...it'd be like user-local. Just think of it as like user-local but an opt. The reason is is that I can't use opt-in. And I guess that would be the same thing with Ruby. We have things that are already in rel that we don't want to overwrite or overbuild. That we want to be able to say, okay, we have an alternative for. And so it competes with what's already there but it's not a replacement for. It's not going to overwrite. It's not going to replace Python 2.7 on EL6 or say Python 2.7 on ELA because I can't say the other name. It's not going to be when there's only 3.6 in this vault. This is only meant to rel or... Yeah, so does that make sense or is it... Yeah, no, I understand that. That would have to be tested and stuff like that but we've already kind of had to test that when the work was done for the 2.6 Python and such. The last thing I wanted to get ideas on is we have a lot of stuff going on for the rest of this conference on containers and modularity. And that is stuff that will affect us a release whenever that release occurs. There's multiple paths for Apple to go. Apple could say, we're not doing it. We're just going to stick to what we have because that's what we have. There is tying into whatever infrastructure modularity is done and working with that. And then there is some variant in between the two. I'd like to get an idea from people who actually use Apple of what they want in this because... Wrong talk. Talk that has all the pictures in it. There's a long ramp up time for any Apple L rel to get picked up. When rel 8 comes out it will be 2 years before there's a large user space available. It will be 4 years before it probably beats what the other releases are currently using at. People are much more slow in adopting things even when it looks like it would be much better for them to do so. Even when they said they would switch all their hardware out to the new rigs. They're very slow, much slower than what people think when they're building stuff. I don't think we have to get it right the first time. We have some time to work around some of the problems and get to whatever we're going to do as 8 comes into play. But we do need to think about it and have policies involved. So from the audience, what are people's ideas on modularity? I've heard multiple people say that they... They're also okay or... You might want to leave the door open because it's starting to... Yeah, or at least I am over here. I've heard multiple people come up and say it sounds like it would solve everything, but... No, I mean there's multiple people, but some of it has been as I've found out when I brought it up. Parts that are no longer in play for where modularity is going to be at certain times. And so it's like, I don't know what modularity is enough yet to know what... I don't think we all know yet because we're baking it. We have a good idea, but as we're baking it, we don't know if the supply is going to hold or if it's going to collapse in certain places. So I do believe it will solve certain things. The multiple trend that Carl here is talking about how modularity will solve one of the problems that IUS sees, words that aren't going to get leaked. Java, most of the financial solutions I had to deal with Java, I had to install four different versions of Java on the same machine and have them all working at the same time. Well, I mean it does, but the finance is where it comes in because the fact is that we can kind of play around with it, maybe get 1.8 to work on all the older ones. But if you have got an Oracle license and you've got a SAP license, that SAP license is to use that version of Java that is for this tool and if you use anything else that you use all technical support on that problem. And when checks are involved, they will... So you'll end up with a system that has 1.4 even though 1.4 is not around anymore 1.5, 1.6, and 1.7 all running at the same time to get a check printed or some similar thing. And so that is the kind of case, but that's actually an SEL problem, not for something else. I'm not trying to solve that with Apple because all I want to do is have one-in-one. The simpler case where Python 2.6 and 2.7 need to be on the same box or 2.7 and 3.7 or whatever Python 3 is at the moment where somebody needs to have both of those things running at the same time so that they can do something. Or the other one that's usually the case is... It used to be PHP where you have two different apps that you needed running, one of them running on one web server that needed PHP, 7.6. something and then something that was 5. something. That type of thing. Now, I mean, in some cases you put those in different containers and that's what you should do or you put them on different virtual machines but products don't think that way. They think you have... You will put it the way that the $10 million license product told you to put it and you will get the software somehow installed by then. But streams won't work for that because I know it won't install two different things at the same time and I'm not wanting it to do that. I'm wanting it more to do the... I want to have this and I need to choose it but my thing is, one of the things I was talking about with this thing too is can Apple produce some streams and another repository produce some streams? What happens when they conflict or when they don't conflict? Yeah, or is only one... the module only be able to be produced from one repository. Most of the things... The reason I put in the ops stuff is I don't expect it... it may not need to be done in 8. It's mainly meant... The ops solution that I was talking about earlier it may be, there will be cases probably but the main reason for it is people will be wanting 6 and 7 until 2020. They'll want 6 until 2022. They'll want 7, I agree but you also know how many people want to put run containers on EL6 and saying the opposite though because they're only allowed to have EL6 in their environment. Sorry, you keep thinking... I keep thinking you're about to ask me something and I keep talking and then you go... So I'm like, okay, sorry. Well, one of the big things... one of the big things I'm wanting to talk with here is I don't want to do the 10-year thing in Apple anymore. It doesn't make sense for... REL has broken that promise. REL itself... The original promise back in 19... I'm sorry, 2007 for 5 years at that time and then became 7 and then became 10 was REL will not change any APIs or APIs or update anything once the release comes out. Whatever you have in that REL it's going to stay the same. You'll backport fixes and additions but you will not break anything. You will not update anything. You'll have to wait for the next major release. That flew for some customers but not for most of them and most customers eventually said well, yeah, that's really nice but we really want that later desktop. We're really sick and tired of this 10-year-old no. We want you to update this. We need you to put this in here so we will use your product and so various things have been brought in newer during these minor releases. Our Apple policy is still built around something from 10 years ago and it's time for us to move to a structure where we match what REL is doing where when a minor release comes out we are able to, when a minor release comes out we're branching off of something and stuff can be updated greatly if a developer needs to be. Currently we don't have availability for anything older than what is pointing to an external repo to coach you. It would require us to get, activate, there's multiple, it would require us getting more storage. It would require us having an external repo that we would then point and stick to. They're all solvable problems. The main issues is a lot of these problems require dedicated time and engineering when all the other things are going on and Apple, for better or for worse, is spare time work from the system. It's been that way. I'm trying to figure out ways to bring in more people who can look at what we've got and then work out how to do this. So it's a great idea if we can do it. We may not have our time and resources to be able to implement it until somebody else does some of the work to get it there. I can go and figure out how to get the U.S. licenses installed and downloaded. I don't have access to the coji stuff to have it be able to point to different repositories of different tree repositories over time. That was one of the big issues in the past where a coji was a black box that you don't touch unless you have black candles, a black booster. Hello, how are you, sir? Can you give a name? Can you give a name? I can announce the name. He's not here, is being looked for? He's not here, is being looked for. Yeah, go get yourself a root beer. It's like a sasperilla, which is a... It's okay. He's not here, we'll be looking for you later. He used Centos for that. It's great for collaboration. We would have to do it out of Centos, because anything that would leak rel packages. I'm working on it. I'll be walked to the door at the end of this day, one way or the other. You actually now know more than Ralph does, and he wrote it. That's something some people have asked for, whether they want... Yeah, I'm just thinking about the port. But one of the things I wanted to say before is I want to thank Susie for sponsoring our talk on Apple. Their open-built system is rock solid. Appreciate their money and time. And with that, I think we're pretty much... We have time here, but I don't see us. The people who were supposed to be here turns out they're in a talk. I needed some release engineers to talk about what things were possible. Although we do have Ralph, because most of the things that we are stuck on are needing some unknown amount of coding in the built system. A matter of... We'll say that you get the... Yes, you fixed everything, but we didn't realize you fixed this and this. Things now will know that you fixed this and then you fixed this. Yes, that's... The main things for it are... What I'd like to be able to do is figure out how to either set it up... Is CBS CoG? I want to set it up, and this is not as much a CoG change. It will be a CoG change, I guess, in some ways, but it'll also be a other relinch stuff of making it so that the faster packages, the CR sent us release type stuff, can be built in CBS. Because one, our CoG is overloaded. The person who walked out of here, Red, Red Hair, Kevin, has been working on a CoG problem, built problem for two days now, because of load issues. It's not... All the other underground stuff that shows up every time we have a big, massive change in infrastructure. Storage is slow, storage is limited. IO is not as big as everyone thinks it is, because everybody wants their stuff at the same time. Those are things that we are... CoG is as 30 terabytes... 60 terabytes of everything, not counting all the new builds that are coming through modularity. Adding in sent us trees... One of the other things is trying to figure out how to deal with sent us external refills. No, no, this is only for the raw hide. Okay, no problem. So this is one of the first things in here, is that I would like to have a faster moving tree set. We had a big... The last couple of major minor releases for rel has broken the world for a lot of sent us users and a lot of rel users, because we could either satisfy the rel users or identify the sent us users during the two or three weeks or month between 7.3 and 7.4, 6.8, 6.9. While we do that, we also found all the crackages that had been moved in and out, that we had duplicates of, that we had to get rid of, that we couldn't see because of certain other problems, and it'd be nicer to have a sort of a raw hide for 7.6 where packages are being built. I called it continual release, but it could be sent through CBS, sent through the sent us CI for testing of install, all various tests, and then built would be available for sent us users. It would have more packages than Apple does because the packages could be... don't have to have a promise on them or we're going to support this. Currently, Apple packages, we've promised that we will support a package for 7 years. So, the next page. So, on the Apple side, so this is in the sent us side. We have this continual release tree available to it where it's built against sent us, packages are being built continually or fast moving. If people want to have later stuff and they don't want to care about nodios changing from 4.3 to 5 because upstream is moved up to 5, they can be on that tree. When 7.5 comes out, when 7.5 comes out, we would branch off of whatever things are and we can see our tree at that time just like a raw hide would. So, Apple would branch off of 7.5 and there would be a 7.5, Apple 7.5 tree. That tree would have... would be built of the packages that people want to be in Apple. So, it's only things like I want to maintain nodios as in I'm going to backport stuff or do whatever needs to be done for that 7.5 to 7.6 release time. Or I have a long-term support release like Media Wickney 1.23 is going to be supported till blah blah blah year so I don't mind putting it in there and they patch it so I'll just drop the patches in and the updates. It's branched off instead of currently Apple every time, every day when releases are done we make Apple into its own repository tree just like it was a release. There's no updates or any of the other sub-trees that we have in Fedora. It's like building a whole new release and if certain things break the Apple release doesn't get built. That takes a lot of resource time on certain things. What I'd like to be able to do is we do that once per release and then updates go into an updates testing and that updates testing then gets pushed into an updates tree. So there's now, just like you have with a Fedora release there'd be an Apple. There's an Apple updates and an Apple updates testing. The smaller tree is easier to compose and can be composed without, and we can track certain things and then when 7.5 7.6 comes out, what we would do is we would build a branch again to 7.5 to treat it like a release. 7.4 would be moved to archives. People who need to have 7.4 for however long they want it can just keep pointing to the archive server and get their old stuff. Won't be updated anymore. It'll be dead. Most of them don't care. They're looking for something that's, you know, their servers are usually rock solid. They don't want changes, but they're on the EUS installs. And so, currently the other big problem to solve is because we compose every day if I have a problem with my package something, you know when we did the change over to pager in source a lot of packages got pulled out of Apple. Nobody wanted those packages out of the side effect bug, but for a couple of days 30 or 40 people packages and their dependencies were all gone out of Apple. Pardon? Yeah. So this is to stop that from happening because 7.4 will be there. 7.4 will be there. Whatever's in 7.4 stays there. There's not a new compose that will also pull those out. Yeah. And that's if you use the same technology and the same methods that we use in Fedora on that versus having a separate set of technology that's where I think Koji and Bodhi and some of the other stuff might have problems with it. I don't know how much work that would take because we're now dealing with multiple moving parts. It might be just easier to just do in the past. Now again, we did have, in slower installs it looked like the better way of doing it is to just do its own thing. Not I'm not trying to exclude CentOS because CentOS people could still use Apple. There's a certain set of people who there's a certain set of CentOS users who want fast moving stuff in route of certain things. They're wanting to continually release the PHP users possibly the I get when I'm dealing with my Nagios packages most of the people want the latest Nagios. They they're very angry that we were out two fifteen years after two fifteen was end of life but that's what rally has been using in certain certain things. I moved it to 4.3 so I'd get old security bugs and close out all these CVDs and such out of 80 tickets I got I have three people who are really really angry because certain checks no longer work they did back there they want me to go back to two fifteen. But that's the thing most of the people want this sort of shorter life stuff and I'm wanting to make it so that we can do that. One of the big issues is that we couldn't do R32 and R32 in our Koji because the Centos cycles and the rail cycles diverge so building against Centos while rail has different things breaks certain Koji orders. Well maybe in eight we can do that in seven and six which is our no it's not it's going to have to be the next one we'll have to the side conversation but it's not new enough because there's certain things that just came in to DNF that need to be no it doesn't live on the same net app it runs on a separate system but there are security and policy reasons why they are separate and the policy things are set by SEC rules and so don't ask me I got in a long conversation with a lawyer one time I just said okay yes those things have not passed those the packages that are in there have not been are not covered on the export control license they are internal built packages that are gotten from access are covered by certain agreements that we have with many different countries on export control. Yes so we have to pull it out of that mirror and then put it back in to a place that's just again don't ask for a technical solution for a legal problem yeah that would be I don't think we're that's a lot of general writing to write a whole different thing to start making different records that would be making COPER to make it separate if I'm understanding what you're asking I was treating it just like another Apple it would just be another repository that you would aim at and the NBR highest NBR wins and again this is a proposal it's not set in stone I'm defending it because it's a proposal but at the end of the day after everyone who's brought everything there may be there are probably good ideas that I'm kind of going oh you can't do that and I'll go at the end of the day going oh that was actually a very smart thing the whole opt Apple is actually a reply to a certain one-eyed person who was against Apple for a long time who wanted this one side thing and it fixes that one problem but I'm not trying to over engineer it to make it solve every problem yeah I mean maybe I don't know the reason I said is 510 was supposed to be the last 5 but 511 did have some rebates just a couple of things but it was just enough to find what were you thinking so broke the world and then we'll probably look at same thing we'll probably have to have the same thing happen when the next major security that big change was because there was just no way you could fix some of the SSL security problems and there's been word that there are other ones coming in so it's like eventually the reason is I just want to say I don't know who you are I will tell you later after this from the mic's off why the conversation I had I just wanted to set your expectations of if he needed to have it if you were thinking it was going to be done next week if you weren't working for it and you didn't know all this crap it could wait till after I think by that point there's so many don't want to add more to them and we've got people freaking out over minor things so trying to make them