WEBVTT 00:00.000 --> 00:20.440 All right, so the next stop we have is about Rhino the next and packed stall towards a rolling 00:20.440 --> 00:25.960 Ubuntu, interesting in rolling distribution in Ubuntu, it's a couple of words I don't 00:26.040 --> 00:30.560 think would have gone together, but let's find out just how well they go together with 00:30.560 --> 00:40.160 Orange Coplo and Adam Solk, or you, yeah, so hello, I'm Adam, I'm VFounder and desktop lead 00:40.160 --> 00:46.440 for Rhino the next and I'm Orange, I'm one of Adam's co-creators and what the system's 00:46.440 --> 00:51.200 lead, thank you everyone for coming to our talk and to the people watching our live stream, 00:51.200 --> 00:54.280 we've got quite a bit to tell you about so we're going to jump right into it. 00:54.360 --> 00:59.360 So yeah, we'll start with some backstory, I first created rolling Rhino remix for predecessor 00:59.360 --> 01:04.840 to Rhino Linux in March 2022 when I was 17 years old, I created the distribution out of 01:04.840 --> 01:09.640 boredom and because I wanted to learn more about Linux to be honest, since I first started 01:09.640 --> 01:16.040 using Linux in 2020, I felt like I needed to learn as much as I could about it and so I came 01:16.040 --> 01:21.720 across a script on GitHub by Martin Wimfress called Rolling Rhino, which converted and existing 01:21.760 --> 01:26.760 Ubuntu installation into a rolling release distribution. Also, price that no one had turned 01:26.760 --> 01:31.640 this novel idea into its own distribution yet, and so with my limited knowledge, I began 01:31.640 --> 01:36.440 to get to work creating rolling Rhino remix using a tool called cubic. While this wasn't 01:36.440 --> 01:41.000 my first attempt at creating this distribution, I still lacked a serious knowledge on how to 01:41.000 --> 01:45.880 get the job done properly. Since rolling Rhino remix was nothing more than a hobby project 01:45.880 --> 01:50.920 for me, I didn't expect anyone to take it seriously. Despite this, I still put it online, 01:50.920 --> 01:55.480 made a small website for it and kept the distribution updated as it gave me something to work on. 01:55.480 --> 01:59.560 The core of the distribution was pretty simple, it was pretty close to upstream Ubuntu, 01:59.560 --> 02:03.720 but as a rolling release. We created a bash script to handle updates and pull the latest 02:03.720 --> 02:08.280 mainline kernels and we also applied our own feeling. More additions came to the distribution 02:08.280 --> 02:13.240 and future updates, we provided a two-year utility to switch between different desktop environments, 02:13.240 --> 02:17.160 finally switched away from cubic towards having our own disk image builder, which paid for 02:17.160 --> 02:21.720 wait for us to ship a server image of rolling Rhino remix, and we had our flagship command line 02:21.720 --> 02:26.520 utility. Rhino config, which I love for people to choose which Linux kernel and package matches 02:26.520 --> 02:30.280 they wish to use, won't package managers, we offered our users was packed all. 02:30.920 --> 02:35.320 So Pac-Sau was created in 2020 by another one of our co-leads who could not be here today, 02:35.320 --> 02:39.480 Henry, and you can read a small blog about it here, we'll also provide this QR code at the end. 02:40.200 --> 02:44.680 His initial idea was a source-based package manager on top of various Linux distributions and 02:44.680 --> 02:49.560 their own in-house package managers, forgetting the most up-to-date releases on certain packages, 02:49.560 --> 02:55.880 but quickly the idea narrowed down to just on top of Ubuntu and APT. So at the start, Pac-Sau would 02:55.880 --> 03:01.640 pull scripts directly from project repositories to build and then gzip these scripts into 03:01.640 --> 03:07.240 its Git repo, which is unfortunately still a problem that plays its cloning history today, 03:08.040 --> 03:12.520 but additionally, Pac-Sau also used a novel idea of tracking files, cisk calls, 03:13.240 --> 03:17.480 for those scripts, for management of those packages, and so for the first eight months, 03:17.480 --> 03:23.240 this was the life of Pac-Sau, but after a while this was obviously not seen as sustainable, 03:23.240 --> 03:28.280 and so a transition to a more standard format was required. The first of these major important 03:28.280 --> 03:32.440 transitions was the introduction of Pac-Scripts, which are simple bass scripts that reflect 03:32.440 --> 03:36.920 format similar to package builds, for package creation, and so at first, 03:37.000 --> 03:42.200 Pac-Scripts would build to a special location and use a GNU store for system integration with 03:42.200 --> 03:46.680 SimWinks, but then it quickly became clear that another major transition needed to occur, 03:46.680 --> 03:50.840 if Pac-Sau's made for Ubuntu and Debian distributions, then it should be creating 03:50.840 --> 03:55.720 its packages as devs. So this combination of Pac-Script inputs to Deboot puts has been Pac-Sau's 03:55.720 --> 04:02.600 standard format since 2022. So as Rolling Rhyner remix continued to develop, it slowly moved away 04:02.680 --> 04:06.920 from being similar to Ubuntu flavor and more like its own standalone distribution. 04:06.920 --> 04:11.320 As some point, our small team had the idea to ship core system updates, including the Linux 04:11.320 --> 04:16.680 kernel and desktop environment, entirely through Pac-Sau, and this idea is what became the base 04:16.680 --> 04:22.360 for Rhino Linux. We got to work building this new distribution, and on the 19th of October, 2022, 04:22.360 --> 04:27.000 I officially announced that Rolling Rhyner remix would become deprecated in favour of Rhino Linux. 04:27.000 --> 04:31.480 It was a risky decision, at least in my opinion, to abandon our previous branding and the 04:31.560 --> 04:36.840 few articles that gave our small distribution some attention. But Rhino Linux was a large departure 04:36.840 --> 04:41.720 from the original Rolling Rhyner in many aspects. And it actually turns out the day that Rolling 04:41.720 --> 04:46.200 Rhyner remix was announced to sunset also happened to be the day that I found the community and first 04:46.200 --> 04:50.200 came into the picture. At the centre of Rhino Linux, I've flagged 04:50.200 --> 04:54.360 it package management wrapper, Rhino package, which was the spiritual success of a Rhino 04:54.360 --> 04:59.560 update utility scene in Rolling Rhyner remix. Rhino package was infinitely more powerful, 04:59.560 --> 05:03.720 rather than just handling the system upgrade, it was intended to be the main package manager 05:03.720 --> 05:07.000 to be utilized across your entire system, with support for app, 05:07.000 --> 05:11.800 pack store, flat packs and snaps. Rhino package detects which package managers are installed on your 05:11.800 --> 05:16.360 system, or query them for packages, and then display a list of packages to install from them. 05:16.360 --> 05:20.520 We created this utility to ensure that people will keep it not just that app packages, 05:20.520 --> 05:25.480 but pack store packages update up to date as well. Rhino Linux diverges from traditional 05:25.480 --> 05:30.280 package management, and how we ship our updates to the end user with multiple managers interacting 05:30.280 --> 05:34.920 with each other. As we mentioned previously, call system utility such as the desktop environment, 05:34.920 --> 05:40.120 an Linux can't or are provided through Pakistan on top of a Ubuntu based app system. And so it's 05:40.120 --> 05:45.880 a priority that uses keep everything updated together. It's also quite early on that we established 05:45.880 --> 05:50.040 our platform ports. I joined the project around the same time that I was working quite heavily 05:50.040 --> 05:54.920 on Ubuntu Touch ports for buying 64. And so with those skills to my advantage, I quickly brought 05:54.920 --> 05:59.000 along a Rhino Linux port to the pine phones and pine tabs. From there, it was clear that we 05:59.000 --> 06:04.360 also had to make a generic ARM 64 ISO, and what is a generic ARM 64 version without a Raspberry 06:04.360 --> 06:09.480 pi version as well. So that's how we came to our three major platform categories. Desktop, 06:09.480 --> 06:14.920 Pine Slash Mobile, and Server. We needed a desktop environment that could withstand Ubuntu's 06:14.920 --> 06:19.800 very unstable development branch, that we based Rhino Linux on. We considered no, but ran into 06:19.800 --> 06:23.720 issues on the desktop environment with our previous endeavors of rolling Rhino remix, 06:23.720 --> 06:27.560 as canonical would often push alpha or beta versions of known to the repositories. 06:28.680 --> 06:33.640 Unfortunately, KDE struggled with similar issues, and so we sailed on XFCE. A familiar desktop 06:33.640 --> 06:38.440 environment that was stable enough on the development branch. Our original implementation of XFCE 06:38.440 --> 06:43.000 was quite standard for a long while, following a design similar to KDE plasma with the task power 06:43.000 --> 06:46.680 at the bottom of the screen, and this took with us throughout the development for our first few months 06:46.680 --> 06:51.800 of beta. However, we realized that we wanted to provide a better desktop experience for our users, 06:51.880 --> 06:56.280 and after some further discussion for Unicorn Desktop was born. We introduced a dashboard 06:56.280 --> 07:01.320 XBOZA, an applications grid, and a spotlight search. This, combined with intuitive key bindings, 07:01.320 --> 07:05.960 made for Unicorn Desktop a powerful desktop experience for Rhino Linux with a similar work 07:05.960 --> 07:11.000 for no-to-nome and the stability of XFCE. Later on in the air, we also introduced optional window 07:11.000 --> 07:16.040 tiling. During this time, we also came to an understanding that being a mostly terminal-oriented 07:16.040 --> 07:20.200 distribution could dissuade a lot of users, especially those with a lack of experience. 07:20.200 --> 07:23.480 We knew it would be important to reconcile this, but with limited resources and a small 07:23.480 --> 07:28.440 development team, developing something like a GUI for package management wouldn't be feasible for us. 07:28.440 --> 07:33.160 To alleviate some of this, we developed our setup wizard to help guide users post-insulation, 07:33.160 --> 07:38.440 install specific packages, and kickstart their journeys. We also developed the Rhino system application 07:38.440 --> 07:42.920 to achieve and display system information and perform updates with the click of a button. 07:42.920 --> 07:47.800 We realized that many users simply prefer graphical front end even if it's performing just a simple task 07:47.800 --> 07:55.080 in the background. As Rhino introduced, a port to ARM64 so-to-did Pakistan. While Pakistan itself 07:55.080 --> 07:59.640 is written in bashing can be installed on any system regardless of architecture, many packages 07:59.640 --> 08:04.040 in its repositories of course cannot be, and with the new ports, certain packages were now 08:04.040 --> 08:10.200 ARM64 only as well. In addition to architecture differentiation in a similar aspect of package builds, 08:10.200 --> 08:16.600 Pakistan at this time also introduced support for differentiation of different Ubuntu and Debian versions. 08:16.680 --> 08:19.880 While this was certainly needed for some of the packages and packed those repository at the 08:19.880 --> 08:24.440 time, this was also heavily motivated by Rhino Linux's need to have packages that were meant 08:24.440 --> 08:29.480 specifically for its customized system. From here we created our main packed-all meta packages, 08:29.480 --> 08:35.080 Rhino Core, Rhino Pine Core, and Rhino Server Core, for handling the install link of the Unicorn 08:35.080 --> 08:40.600 desktop or lack their hub for server addition, and any other device specifics that were required. 08:40.600 --> 08:44.520 We also introduced at this time support for the priority control field in Debian, 08:44.520 --> 08:47.800 so that these core packages could be marked as essential to the system. 08:48.680 --> 08:52.200 This then became the development progress of Pakistan over the next several months, 08:52.200 --> 08:56.040 going back and forth between adding or adjusting support for features and package builds 08:56.040 --> 09:00.360 and support for features and devs. Some of this was as simple as renaming variables and 09:00.360 --> 09:05.080 pack scripts, but which meant repository wide breaking changes, and some of this was more novel 09:05.080 --> 09:10.120 where Debian and Arch have fundamental but sold differences in what the names of variables mean. 09:10.200 --> 09:14.360 To mediate this difference, packed-all will often mimic Arch's behavior on the building of 09:14.360 --> 09:18.920 packages, but as the output will be a dev, will often perform extra functions on top of the 09:18.920 --> 09:26.760 traditional APT install to smooth out that behavior. So from April through to August of 2023, 09:26.760 --> 09:31.240 we channed out seven beta versions of Rhino Linux, before making with decision that Rhino Linux was 09:31.240 --> 09:35.960 in the cohesive and stable enough state to warrant our first full release. 2023.1. 09:35.960 --> 09:38.920 We've produced a blog post with members of the team detailing aspects of the 09:39.000 --> 09:42.200 distribution that they worked on, and published Rhino Linux to the world. 09:42.200 --> 09:45.800 And just to brief slide note about our versioning scheme, while we are absolutely a rolling 09:45.800 --> 09:49.800 release distribution, we provide snapshot disk image releases throughout the year to indicate 09:49.800 --> 09:53.960 a significant amount of major changes, or when the previous release has become too far behind on 09:53.960 --> 09:58.840 package updates. Since I release, we've had to handle both our community growth and release planning. 09:58.840 --> 10:02.680 Our shifted our release road maps and cambam boards and moved them over to GitHub as it would be 10:02.680 --> 10:08.120 more public and accessible, and we had to also have to handle our community growth. So we added 10:08.120 --> 10:12.280 additional onboarding and security to our discord service, and we took the hard decision to close 10:12.280 --> 10:16.280 our major extremes as we didn't have for people in place to keep an active and moderate to. 10:16.920 --> 10:21.800 Another issue that has persisted with us when providing releases is the need for download 10:21.800 --> 10:28.520 mirrors. GitHub releases the size of release binaries to two gigabytes. So we have to move to 10:28.520 --> 10:33.560 sourceboards pretty early on for providing our main releases. However, as many users have pointed 10:33.560 --> 10:38.360 out to us, sourceboards is slow, and so we have continued seeking additional mirror providers. 10:38.360 --> 10:42.760 For a few months, we had a user assistant providing a mirror, but they eventually had to shut 10:42.760 --> 10:46.360 it down because the cost of hosting was set to increase due to too much traffic from us. 10:47.240 --> 10:51.560 So this dichotomy between reliable services which are hostile to open source projects and 10:51.560 --> 10:56.040 require lots of funding and free services which are friendly to open source projects, but at the 10:56.040 --> 10:59.480 cost of speed, has consistently put pressure on us as a development team. 11:00.440 --> 11:05.000 After our first few releases, we've attempted to branch out from some of our initial ideas, 11:05.000 --> 11:08.920 and we launched for Unicorn Beyond Access E initiative, and aim that was see contributors 11:08.920 --> 11:13.640 and community members design industry spins of Rhino Linux with different desktop environments. 11:13.640 --> 11:18.600 UBXI unfortunately didn't meet its desired aim and had little momentum, but it still exists 11:18.600 --> 11:23.480 as a core package for Rhino Linux to allow for you to remove the Unicorn desktop and to replace 11:23.480 --> 11:28.120 it with a different desktop environment. For strain of being full-time students, having jobs, 11:28.120 --> 11:33.000 and managing a Linux distribution as a very small team began to weigh on us. We were at our breaking 11:33.000 --> 11:37.960 point as a team and individuals, a feeling that most people in the open source development community 11:37.960 --> 11:42.600 can likely resonate with. The project had begun to lose its spark, and none of us were really 11:42.600 --> 11:47.400 enjoying working on it anymore. Our culture as a young, small and strained team obviously became 11:47.400 --> 11:51.560 somewhat polluted as a result of its burnout. It takes a lot of work to continue to improve 11:51.560 --> 11:55.880 the project as large as Rhino Linux, and as students, we didn't have the most amount of free time 11:56.120 --> 12:02.120 to work on the project. Me and Rhino will begin to argue frequently, and our activity 12:02.120 --> 12:06.840 within the organisation fluctuated, it became clear that we needed to change over project 12:06.840 --> 12:12.840 when it survived. It's taken us a while to then help to keep our distribution and development 12:12.840 --> 12:17.080 in a stable state. We've been asked many times about Rhino Linux, why base are rolling 12:17.080 --> 12:21.800 release on Ubuntu, why not art or at least Debbie and Sit, and the simple answer is because 12:21.880 --> 12:27.960 a plethora of those already exist, but not that. All of us working on the project have grown 12:27.960 --> 12:32.440 up within a finitifruble into one way or another and pushing it to them, it's exactly what 12:32.440 --> 12:37.080 we're intending to do. However, at the end of the day, this is exactly what Rhino Linux is 12:37.080 --> 12:41.640 biggest pain point and source of struggle is, being based on Ubuntu, while breaking from Ubuntu's 12:41.640 --> 12:46.360 traditional release model. The development branch that Ubuntu provides is absolutely more unstable 12:46.360 --> 12:51.240 than Debbie and Sit, and often receives package updates sooner, which is sometimes a benefit 12:51.240 --> 12:56.680 to us, but sometimes is a cost. One of the most notable examples of this being a problem is the 12:56.680 --> 13:02.920 infamous XCU Tiltback Door from last year, as seen in the mean. But sometimes, both Sit and 13:02.920 --> 13:09.000 develop it, like in the case of last year's shift to 64-bit time on the majority of packages. 13:09.880 --> 13:15.080 So, in addition, there are also often several builds of a package update before it is considered 13:15.160 --> 13:21.560 stable as Ubuntu will apply opinionated patches that Debbie and Will then drop. These patches 13:21.560 --> 13:26.680 are usually relating to snap and app on our kernel support, which we do not provide by default. 13:26.680 --> 13:31.000 And in consequence, has caused breakage in Rhino quite a few times, where we have then 13:31.000 --> 13:35.720 added to jump to fix it by providing hot fixes through pastel. Very recently and not for the first 13:35.720 --> 13:40.360 time, this breakage popped up for us in the pipeline audio library, where Ubuntu frequently 13:40.360 --> 13:46.920 pushes these types of opinionated and untested patches. After burning out myself and Oren, 13:46.920 --> 13:51.320 as co-leads of the distribution, sat on a video call for the first time ever, and opened up to 13:51.320 --> 13:56.040 each of her about our concerns, both with balancing our personal lives and about our organisation as 13:56.040 --> 14:00.520 a whole. We opened a discussion up to the rest of Rhino the next team, and held an in-cooled team 14:00.520 --> 14:05.160 discussion to allow for everyone to voice their opinions. We published a blog post, which details 14:05.160 --> 14:09.960 these issues that were facing as a team, and delayed the next release of Rhino Linux indefinitely 14:09.960 --> 14:14.120 until we resolved these issues. We were still continue to work on the project in the meantime, 14:14.120 --> 14:17.880 but we took a step back and slowed down the pace at which we were working, and it helped 14:17.880 --> 14:22.520 to alleviate a large part of our stress. A little while later, we came back with four changes that we 14:22.520 --> 14:26.920 made happen. We provided a strong contributor to code a conduct to ensure that all contributors 14:26.920 --> 14:31.560 of Rhino Linux projects, including members of Rhino Linux team, had guidelines to adhere to, 14:31.640 --> 14:35.880 with mutual respect, and that's going for help to become core tenants of Rhino Linux philosophy. 14:36.440 --> 14:41.000 We outlined that goals as an organisation through our mission statement. We did a full 14:41.000 --> 14:45.160 overhaul of our website blog and wiki. Our blog and wiki were now being served with next 14:45.160 --> 14:49.960 year, and our pages completely written in Markdown first, reducing the barrier to contributing 14:49.960 --> 14:54.200 to them. And our development channels in our discord were streamlined to help facilitate 14:54.200 --> 14:58.440 the development further and make it easier for potential contributors to engage with the project. 14:59.320 --> 15:03.240 Incoming back, Paxel also had several major overhauls in the last year. 15:03.240 --> 15:07.400 It's began with the addition of switching from singular source variables to full source arrays, 15:07.400 --> 15:11.720 so that packages could pull source data from more than one archive at once. Shortly after, 15:11.720 --> 15:16.040 we introduced array extensions for both architecture and distribution versions in a similar 15:16.040 --> 15:20.600 fashion to Paxel builds again, but with an added layer of complexity in combining 15:20.600 --> 15:25.400 distribution and archerrages as well. On the deviant end, Paxel introduced support for 15:25.400 --> 15:30.440 version constraints on dependency fields so that packages could be more accurately handling distribution 15:30.440 --> 15:36.760 version compatibility. There's also been adding of support for split packages, allowing 15:36.760 --> 15:41.800 multiple dev outputs to create from a single Pax script, utilizing the package-based variable 15:41.800 --> 15:46.200 and turning the package name variable into an array, a feature that has taken several rewrites to get 15:46.200 --> 15:51.400 right. Alongside the management of split packages also came the introduction of source info 15:51.400 --> 15:56.920 files to packages, mirroring the format again of arch, allowing packages to have a static output 15:56.920 --> 16:01.720 of key information for external programs to then be able to read. Another major change to Paxel 16:01.720 --> 16:06.200 that required quite a few rebalancing changes before it was in the stable state was the integration 16:06.200 --> 16:12.360 of B-Rap for Paxel's construction, meaning packages are built in an isolated environment 16:12.360 --> 16:17.640 greatly increasing the security of Paxel's construction. More recently, Paxel also introduced 16:17.640 --> 16:22.120 support for internationalization and localization to ensure long-term maintainability of the 16:22.120 --> 16:26.760 program and a stack trace function that is seen in standard programs like Python and Rust to 16:26.760 --> 16:32.760 catch internal errors. Finally, with solid source info data, we were able to greatly improve 16:32.760 --> 16:37.320 our package API and provide important build information details through adjacent format so that we 16:37.320 --> 16:41.880 can then parse this data in other programs. The key program that our API is most important for 16:41.880 --> 16:46.200 for us is our most recently launched project which has been an development for over two years 16:46.200 --> 16:50.760 and has also taken several rewrites to get right. In a similar vein to Arch Linux's chaotic 16:50.760 --> 16:55.560 R which provides pre-built packages produced from package builds, we have launched the chaotic 16:55.560 --> 17:02.520 PPR or Paxel pre-built repository. The PPR is an APT repository that Ubuntu and Devion users can 17:02.520 --> 17:06.840 install on their systems to receive certain requests of packages from Paxel which may or may not 17:06.840 --> 17:14.600 have a long build time. We also provide the depths for Paxel in this repository. Then the package 17:14.600 --> 17:20.200 changes are produced to their source info data, the source info data is read by the API and the 17:20.200 --> 17:25.880 PPR can then read from the API to determine what packages are allowed to be added and what configurations. 17:26.440 --> 17:30.600 The biggest piece holding the PPR back though was not the development of it. As we have already 17:30.600 --> 17:34.920 alluded to, the biggest challenge has been securing the support and funding for a server large and 17:34.920 --> 17:39.640 fast enough to just host and distribute these packages. This currently running on a cloud container with 17:39.640 --> 17:43.880 one terabyte of storage which feels like a lot when we take into account that there may be 17:43.880 --> 17:48.760 multiple versions of package, multiple architecture output builds and multiple distribution 17:48.760 --> 17:54.040 specific output builds all being hosted here. We realize that we can absolutely reach the limit 17:54.040 --> 17:58.600 and quicker than we would think. Scaling the PPR to be more sustainable and larger network, 17:58.600 --> 18:03.000 although our deal goal is not easy to achieve as a small open source project. 18:03.560 --> 18:08.040 It's not really a big secret then that we're quite an ambitious team. I can give numerous examples 18:08.040 --> 18:13.000 of projects that we have worked on announced and then ultimately dropped scale back or had slow 18:13.880 --> 18:17.400 progress on. Now this can be for a multitude of reasons but it usually either boils down to 18:17.400 --> 18:23.400 maintain a burnout or is not realizing the full project scope quick enough. Some project examples 18:23.400 --> 18:28.680 could be Rino Package 2, a full rewrite of Rino Package in new shelf. That has been extremely 18:28.680 --> 18:33.160 stored with its progress and development being quite on again off again. The same could be 18:33.160 --> 18:37.880 several eye compact unicorns with development being stored repeatedly since the projects inception. 18:37.880 --> 18:42.360 We will also go into create a flag style set of system but that never came to fruition beyond 18:42.360 --> 18:48.120 an initial concept. It took me a large while to realise that it was okay to ask for help 18:48.120 --> 18:52.040 and that it wasn't a sign of weakness or would damage for a reputation of the distribution. 18:52.040 --> 18:57.000 Myself or in the rest of Rino Linux team can only put in so much of our free time 18:57.000 --> 19:01.160 into this project and we want to keep building awesome things for our users and to improve 19:01.160 --> 19:05.960 the distribution and we have a lot of big plans but some of those plans do require more work 19:05.960 --> 19:10.920 and we are able to put in at the moment and so in November of 2024 I made a call for contributors 19:10.920 --> 19:15.080 and it had some success bring in additional members into our discord who some of whom who have 19:15.080 --> 19:19.480 made great contributions to our project. We aren't letting go of the aforementioned projects 19:19.480 --> 19:23.640 that have been stored for rewrite of Rino Package and the release of our unicorns icon pack 19:23.640 --> 19:27.480 are both still very much in the works and on the table. We have further improvements that we 19:27.480 --> 19:31.880 want implemented into unicorn as well like an integrated settings program for easily configuring 19:31.880 --> 19:37.480 with desktop and over quite ambitious and the eventual transition to Wayland. Similarly we still 19:37.480 --> 19:42.040 plan to create UBX iPods and potentially provide multiple disk image spins with different desktop 19:42.040 --> 19:47.480 environments pre-installed. Pine 64 devices will be for first receiver treatment as we are actively 19:47.480 --> 19:52.280 looking at a new turn at alternative mobile environments. Additionally we plan to release a 19:52.280 --> 19:56.520 server edition for devices over than the Raspberry Pi but we want to develop a proper lightweight 19:56.520 --> 20:01.400 installer to be able to do so. Finally we will mention it one last time but we recognise that 20:01.400 --> 20:06.360 if we want to realize our long term goals we need more funding. After several discussions we believe 20:06.360 --> 20:10.120 that the best way for us to ensure the longevity of the project is to create an official 20:10.120 --> 20:15.320 Rino Linux foundation. However as we have also made clear we are young and quite new to this 20:15.320 --> 20:20.040 so we admit our inexperience. If any of you have advice on how we can maintain our forward path 20:20.040 --> 20:24.680 and in a financially feasible way we would be more than happy to talk to you after this. 20:24.680 --> 20:28.920 Thank you for coming to our talk. Thank you. 20:29.240 --> 20:43.240 Any questions? Any questions? 20:43.800 --> 20:49.720 Have you guys heard of the micro mirror project? No. No. Fantastic. I would love to send you 20:49.720 --> 20:51.960 links so I will do that. Great. Thank you. 20:59.640 --> 21:07.640 So being in front of Ubuntu like the next race you tried contributing to you going to 21:07.640 --> 21:11.880 itself and to fix their mistakes or are just suffering from their changes. 21:14.040 --> 21:20.360 We don't directly contribute to Ubuntu. We suffer from their changes mostly. 21:22.360 --> 21:28.520 We find that although the development branch is absolutely faster than said it is still too slow for us. 21:29.160 --> 21:33.320 We need to push those changes out the day that they happen and so 21:33.320 --> 21:37.640 Pakistan is the best way for us to provide those and we also recently actually introduced a new 21:37.640 --> 21:44.600 utility called Rino Hotfix which performs a function similar to a pack script but with a little 21:44.600 --> 21:50.440 less safety involved as some of those Hotfix's require more integrated fixes. 21:52.440 --> 21:56.600 So I just want to say thank you for sharing your story. I think a lot of people in the 21:56.600 --> 22:01.320 room have gone through burnout and open source projects and the maturity of shown and how you 22:01.320 --> 22:06.920 have addressed and how you've kind of put things together. I was impressed. So thank you very much for 22:06.920 --> 22:10.760 sharing your story and thank you very much for taking the initiative to make sure you're an 22:10.760 --> 22:12.760 healthy project. Thank you. 22:29.720 --> 22:33.960 So how do you make sure that these two packaging forms that you have and actually the third 22:33.960 --> 22:38.520 stack of patching on top of that? Don't interfere with one another. Do you 22:38.520 --> 22:45.800 install things to different file trees? Do you have containerized stuff? So how do you 22:47.000 --> 22:53.240 manage to have a file hierarchy built out by debt packages and then have another packaging 22:53.240 --> 23:00.040 system on top that has maybe similar software components in those packages? How do you manage that? 23:00.040 --> 23:07.080 So Rino package when it does an update, it first performs the APT updates and then it 23:07.080 --> 23:12.520 performs the pack style updates on top of that because in reality a pack style package is really 23:12.520 --> 23:19.000 just turning into a dead package at the end. So we expect that there will be conflicts and we 23:19.000 --> 23:27.560 write our packages to be prepared for these conflicts. But as we have mentioned, it is vital for 23:27.560 --> 23:32.200 users to be updating their packages with our main package manager as opposed to using the individual 23:33.080 --> 23:36.520 ones to ensure that all of those updates are done in the right order. 23:43.240 --> 23:46.040 It looks like that's it. So thank you again. Here.