 Okay, so welcome to Tiger West, a floor remix, and so my name is Tim Sable. I'm a student at the Rochester Institute of Technology in New York, and I'm the president of Britlove at the university. And together we've kind of put together a remix for our university as a club, and so it's going to give you guys some background, why we did it, and all that kind of stuff. So about Tiger West. So first and foremost it's a student-led project at the university, and it being for five students, four students, it's had a lot of challenges with working with the, like working with students while you are a student. Can you guys all hear me? I don't even check. So being a student is always challenging between your school load and your outside activities. And so working with a floor remix has been a very interesting and challenging process. And so in the next slide I'm going to tell you guys why we made it. So in case you guys are not familiar with what a floor remix is, it is a combination of Fedora software that is made by anyone in the community, as opposed to a spin, which is all Fedora software that is a different desktop environment. And it's also, importantly, all free software. While a remix does not necessarily have to be all free software. And remixes specifically have a specific purpose for why it was made. They tend to cater towards a very specific group of individuals. And so Tiger West is aimed towards both new students and old students and faculty. And so this means that Tiger West has RIT specific branding and software that is very specific to our university that Fedora would not have in its own package rebos. And so its main goal is to smooth the line with new users of Linux with their course load. Because at RIT a lot of the introductory courses as well as the advanced courses focused a lot on using Linux as with our class activities. And then so what are exactly our goals? Why did we make Tiger West? So the goal is to help new students get streamlined into using Linux. And these students typically use Windows. They typically come from a Windows background and Linux has a very different feel to it. So in order to smooth that line, we want students to not have to use the terminal. So with that being said, our ultimate goal is to aid students in the classroom by having all of their software that they need readily available. So if you're a computer science student, when you first boot up Tiger West, there is actually a screen that will come up and ask you what your major is. And then after that it will ask you what kind of software you want to install. And then it will install everything that you need for your major without ever needing the command line. And this can be very useful for a new student. And they just want to get their work done. They don't want to have to learn Linux. And so it creates a very interesting ecosystem with where you can get your work done at the same time you're using Fedora, you're using Linux. So it's a very familiar feel that while using an unfamiliar product. So some of the history, some of the background of how it was created. So back in 2011 is when this project was initially built. But it was built as the RIT, the RIT Linux, Fedora remixed, sorry. And so it was created by Lubb Makin and Etan Rubinov. And however, these people were also students. And once they graduated, the project kind of diminished. It kind of got forgotten in a couple of years. And so in late 2016 or so, a student found the project and we decided to bring into a club vote as to should we pick it up? Should we rebrand it? Should we change anything about it? And so a little bit of time went by. We weren't really sure if this is something we wanted to do or not. But then in February of the next year, we decided to pick it back up. Our project lead decided it would be a great thing to do. And so we decided to rebrand it as Tiger West. And this time we had a new goal in mind. And so the current features that we have is the known desktop environment. This is also, as you know, what Fedora has as their default. And then we also have the better default user interface. And of course, better is very subjective. But coming from a Windows background with these students, we figured it would be a good idea to have a panel at the bottom to very closely resemble what Windows users have if they're a star menu. And so we have used dash to dock. And we've rearranged some of the icons that made them into a panel. And so that way they have a good nice feel that they're already familiar with. And in addition to that, it uses the Anaconda installer, which is also, actually, I think Fedora moved away from that in this, in through our 28. They moved to a known installer. And Anaconda is amazing because you don't need to use the GUI in order to install everything that you need. It does have a terminal installer, which is what kicks our files use. And so we've also included software that is available for these students to use packages that the students need for their daily workflow. And so not all of these packages that they use have actually been created as RPN packages. So half the work that we have to do is create these RPN packages that these students need so that they still get updates and they still get the fixes that they need in order to get their work done. And so this is what the fresh default look of what Tiger West looks like. So as you can see, you have the panel at the bottom. The dock is a little bit smaller, it's a little bit thinner. And then we also have the logo, which is a Tiguan. So it's a penguin, and then it's also the tiger, this is our mascot. Kind of merge them a little bit together. You have a nice little penguin there with some nice tiger stripes on there. And so now that we have our initial project up and running, how did we actually do this? How did we go from nothing to a working project? So the main thing was trial and error. So the current infrastructure that we had to use is nothing like what Koji uses, what Flora uses for their own ecosystem. So the Koji infrastructure, if those of you are familiar with it, is too large for a small project. And so that means that we need to create our own infrastructure to support the building of packages and a project mirror. So in order to solve this issue, we've had to go through a lot of trial and error of how do we actually manage creating these packages? How do we manage serving them on a mirror without a lot of overhead? So in order to solve this issue, we first started with a single server that hosted both the builder and the mirror. But we quickly found out that this is not a very good idea because if the builder went down, if the mirror went down, then they both went down. So what we decided to do was have two separate servers, one with the builder and one with the mirror. That way, if one goes down, the other one stays up and we can still get some work done. So in order to, and then after that, once we had a lot of some of this stuff done, we had to ask a lot of questions. We were coming into a new project in a new field that we weren't entirely familiar with and so we needed to find out a lot about how to actually find some answers. So in order to fix our main infrastructure problem, we had to ask a lot of questions. So going into the Fedora IRC channel was a very, very great help. And so we had to also figure out what structure do other remixes follow? What would work best for a smaller project that still mimics what Fedora is doing with their own infrastructure? And also we had to answer what if the builder uses too much, too many resources or what if the mirror gets pulled with too many times? And so should we just have one mirror and one builder or does multiple of each make more sense? And also with all that being said, there is not a lot of documentation that actually supports and gives a step-by-step on how remixes are actually built. So a lot of this is actually trial and error with everyone who comes with a remix because there isn't that much information available for the creation of a remix. It was available for what they are and what they do, but not necessarily for the creation. And so furthermore with all that being said, why Fedora? Why not Ubuntu? Why not Arch? Why not anything else? So the main reason is we wanted things to be easy and very simple to do for someone to come into the project. And also we wanted very little overhead with the learning curve. So with Fedora, the process of making an ISO is so easy. With a kickstart, ISOs are just a breeze to make. Being able to easily specify what packages you want, you can easily take out packages, add more, and it allows for terminal installation of Anaconda, which you can really ask for much more than that. And no other distribution can really offer that level of flexibility. We've tried between Ubuntu and Fedora and Ubuntu is just not as smooth. It's not as a lot more steps that you have to work through. And when you make a lot of custom packages, time is really of the essence. You don't wanna be spending a lot of time creating the packages. You just want them to be built and work on the next one. And so the process of building RPM packages is also very simple. With a simple spec file, it's very simple to put down exactly what you need done, what files you need put there. And that's essentially it. It's essentially just a wrapper for the source files that already exist. And that furthermore is the ease of use. With Fedora, the default being known, it's very simple, user interface to use. And we wanted to use something that was simple and somewhat familiar and was very easy to learn. And so we actually started off with different desktop environments before we decided to settle on known. We actually initially started with Cinnamon, but Cinnamon had its own set of issues and problems, even though it is actually more similar to a Windows experience compared to known. And then also, with recent editions of third-party repositories, we've actually been able to have our repositories. We have our own custom Chagr-Rest repositories. We are now able to put them into the known software. And this makes it very, very simple to have students find the software that they need. And then so, challenges that we've come. So the first is that we started with an old project. And whenever you pick up an old project that you have never seen before, it can be very hard to sift through all the information of what has been done, what needs to be done, and how to do it. So in order to solve this, we've really had to look through the project and decide, is there anything that we can continue with? Do we know what the current goals are? And if not, can we create goals using this? And so we had to decide that, no, we didn't actually want to use this. So we took the ideas that we thought we could gather from the old project and rebuilt it into what it is now. And also, with the Flora infrastructure being too large for the project, we had to really figure out what we needed to do to scale it down if possible. And so we spent a while working with Koji to try to figure out, is there a way that we can make these bills work without having to build our own infrastructure? And after a lot of discussion, we've had to kind of decide that at the moment, we need to have our own infrastructure. And then also, and last but not least with the documentation, it was very hard to find documentation. And there actually wasn't any at the time. So we've had to spend a lot of time kind of figuring out what we needed to do. And while we're doing that, we've also written down a lot of what we've had to do. And now it's just some remix documentation on how to build them. And then so with all that process, what did we learn with building a project? So projects are a lot bigger than you really think they are. It's very hard to, when you set a goal, it's very hard to adhere to that with a release schedule. And so we've kind of had to learn that firsthand. It's very hard. You set a date a couple of months in advance to be able to make that goal, to make that date. And so nobody really kind of expected that. And we've really had to learn. And now, instead of setting goals that we really wanted to hit, we have to be realistic and kind of understand how long it actually takes to build a large project. And also, there is the project management. You have a lot of different varieties in the people who work with the project. And it can be really hard to figure out who is good at what, what people do best, and also the different dynamics of people and how they work. And so it's been a very interesting challenge to kind of manage a group of people and manage a group of students around workloads and figure out what works best, where people fit best, without having much drama going on. And then so the last part is we also have all the design that we've had to do. It was also custom made for us with one of our students. And they had never really used open source design tools before. And so using tools like Krita has been an amazing tool in order to create some of our designs that we've had to do. So all of our wallpapers and mascots and emblems are all custom made. And it's been a very interesting process figuring out how the best way to make these things. And so with that being said, how did Fedora help us? How did Fedora remixes help us to build what we wanted? This is essentially a tool for students to make their lives a little bit easier. And so remixes really helped us because they allowed us to reach a target audience a lot quicker and easier than we would have if we had to create our own distribution. And with that being said, we've also been able to keep all the updates that Fedora guessed that they're a normal product. And this is extremely important because when a Fedora makes an update, we also get an update. And so that way we don't have to focus on our own updates and we don't get an old product either. And so remixes are an integral part of the Fedora community because Fedora itself can't get into niche markets without the help of remixes. They really are able to get and target a small audience and they don't need to work with Fedora in order to do that. And people who use Tigera, people who use remixes are using Fedora. And it really gets everything out there and really gets the community surrounded in many different aspects. And so we use everything on GitHub and so if anybody wanted to contribute, we have our GitHub page there. And so we also have a lot of documentation and package ideas and development. And so what are our future features and goals? What do we wanna do in the near future? So one thing we really need to work on is having a software installer. And so one of the things that we need to do is start getting all of our repos to be either available in the known software center or we need to figure out if we need to create our own package installer. Because our goal is to when a student installs this for the first time, a queue we will show up and kind of walk them through the process. And so at the moment, what we have is just a terminal installer. So it does everything that we wanted to do. Ask for your major and it'll sell all the packages that you need. But our goal was to use a, to have them not use a terminal. And so that is one thing that we will need to figure out. And also one thing that we have been doing is everything manually. And we really need to figure out the best way to have continuous integration for building packages and upholding up the mirror. We don't want to have to build packages manually every time we make a new version, make a new update. And so figuring out how to get a package built and then signed and then pushed through the mirror is going to be a challenge that we're going to have to eventually get through. Because it would be very helpful if we didn't need to have to wait for one person to sign a package or for one person to move it over. Because currently we have one person doing the package development and one person is working with the mirror and the builder in order to get everything working together. And also we would like to have complete documentation on how to use the product but also how to build a remix. So it's a very ongoing process and having complete documentation would allow other members to build remixes much more fluid, learn from our mistakes and have a lot better time developing a remix for their own needs. And so with that being said, that is the end of the presentation. And so if you wanna contact at all, our website is up there and also if you wanna talk to me, you can find me on IRC. And thank you. There are any questions at all? I was curious, what are you actually using for the builder? Like how is that build processing done as of now? Sure, so for the builder we use a Flora server. And so what we do is we use the Cobra RPM build package and so it'll pull from the get repo where it exists, where the packages exist and then it'll put everything together and build a package into an RPM package. And RPM packages have both a source and a regular RPM package and then they get sent to another directory where someone then signs that and then puts that to the other server up to the crack location on the mirror. Okay, what's some of the specific like software that's made available through the Tiger West for possible use? Sure, so some of the software that is available for the, say for the CS major is PyCharm, Python, and also program Jflap and also making sure all of the, like GCC is already on there. And so we actually had to package PyCharm ourselves but with the third party repositories we now actually have been able to get rid of that and you can just install PyCharm from your own software itself. So that's been really helpful for us. And so with the other packages is actually it's still an ongoing process because our current goal is to have it for all of the tech section of our university. And I suppose even with the other sections because they like the math and engineering building do have packages as well. And so we currently have completed the CS, the IT, and the software engineering major and we still have two more to go. Do you think some other universities could use this pipeline, this infrastructure that you have built? Do you think that they could use it like for their own spin, let's say? Or in other words, do you plan to contact universities or did you think about this? Yeah, so our current status of the project is we are trying to hit a, actually we will hit it actually, a beta release in the beginning of the semester which is in I guess like three weeks or so. And so once we do that, we're going to make an announcement to the students and to everyone that is now available because there's been people following it but not many people have been using it yet just because it doesn't have all the functionality that we really wanted to have. And the university does actually know of the project already. And one of our ultimate goals is to get it onto the CS machines because right now the machines that students use for their classes in the computer science department are they run Ubuntu and it would be really nice if we could get TigerOS onto those machines because some other departments actually use rail on their machines. So it would be a relatively streamlined experience to move from Ubuntu to TigerOS. So we've had to contact first the CS department head and then they've had to contact a few other people and they will have to in order to get that all set up. So once we hit our final release which would have everything which would have all of the majors that we want, all their packages all ready to go and also the GUI installer is the main thing that we really need to think how we need to do right now. Once we get that, then we really will be trying to streamline this into the full university. And it would actually be really interesting if we could, once we get the whole project completed, we really want to try to build a tool for any other university to make their own repo, their own remix because there have been actually other universities that want to try to do this but they don't really want to have to go through the whole process again. So it would be really nice if we could make a kind of a tool where they just input some simple information and it will build a remix status base towards their school. And so that would be a really great way to get through our out to university students in a very easy to do way. And so that would be kind of the ultimate goal would be to give universities the chance to be able to easily make a Linux distro without having to put too much of their own effort. They don't need to do much building on their own and that is focused towards their students and not just a generic distribution. Because that would be really cool and it really gives students like an adoption because it's their school's distro. So that would be, that's kind of the ultimate goal to kind of bring it down to give Linux to the younger students and just being able to give it to students who wouldn't generically use Linux would be a great way to kind of like spread open source to lots of communities I wouldn't really expect. I think it actually changed with the recent change of the documentation but it lived in the Fedora docs slash remix building is where our current documentation lives and it is for how to build an ISO and how to build RPM packages and it also lists how to set up two servers that you'll be needing for the builder and the mirror. So if you wanna see how we have our infrastructure set up you can also visit that a little bit more. So it would be on the Fedora docs website? Yes. I was gonna try to pull it open here. So it would be under the Quick Docs session? I think they changed it actually. They did. God, I'm gonna have to figure out where they put it then. Is there a Quick Doc in a different place on the sidebar? Yeah, because it used to be at the very top that area. Okay, so it did move. So, thank you for everything we know. I guess I need to figure out where they moved it to. Well, it's at least here. This is where it gets made, but I don't know where. I don't know where in the docs I guess they got moved to. But, any other final questions? All right, well, thank you guys all for coming to the talk. Have a good one. Thank you.