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