Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
  • Loading branch information
github-actions[bot] committed Aug 10, 2024
1 parent a616312 commit fb55f1d
Showing 1 changed file with 15 additions and 39 deletions.
54 changes: 15 additions & 39 deletions docs/about/how-huronOS-started.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,53 +2,29 @@
sidebar_position: 1
---

TODO: Rewrite this text for new website
# How the Project Started

# huronOS history
huronOS starts its development by Enya Quetzalli in 2019 as a prototype of a distribution for competitive programming.
huronOS has undergone several stages leading to its development as a comprehensive system.

Why huronOS was needed in first place
In 2019 Quetzalli wanted to help her university hosts the early classificatory contests (4 contests) for the ICPC by doing coordination, logistics and learn how to configure the programming environment required for the contest. A lot of problems surged during the programming environment process because the university was not allowing the installation of any operating system on the institution hardware, any modifications were available to be done during the weekdays.
### The Need for a Solution
Universities hosting ICPC or IOI competitions require a contest environment that is meticulously prepared and compliant with all contest rules. Achieving this goal can be challenging for many institutions, leading to temporary solutions such as Virtual Machine images, live USBs, PXE boot systems, temporary OS installations, or manually saving and restoring data before and after competitions to facilitate training camps.

1st contest: The first contest used a virtual machine image under the supposition that all the university computed had the VM software installed, this was not true, and results were poor and not equal for all the teams.
The Superior School of Computer Sciences (ESCOM-IPN) faced similar challenges. The team responsible for the ICPC environment developed a solution known as 'contestImage,' a simple Ubuntu live USB with persistence. However, they quickly realized that to maintain a clean environment, they needed to flash each USB (sometimes over 70) before every competition round. This process was time-consuming and did not allow for a traditional 'warmup' contest without contaminating the filesystem with pre-competition code.

2nd contest: On the second contest, the computers had a GNU/Linux distribution installed, but this was not complying with all the ICPC requirements.
The team identified several areas for automation: setting up wallpapers, cleaning the filesystem, switching firewalls between a practice online judge and an official competition judge, enabling or disabling software based on competition type (IOI-like or ICPC-like), and more.

After all of this, Quetzalli proposed preparing live-USB systems to hold the contest. This was the seed for the development of huronOS.
While some automation was achieved, such as wallpaper setup and a basic script for filesystem cleanup, it became apparent that implementing all desired features would require significant effort.

The Contest Image
After accepting the challenge, Quetzalli decided to build a simple image of a persistent live system by taking Ubuntu Budgie, making it persistent using Rufus utility and then install ICPC software, a basic firewall and setting a shared wallpaper for the image. Took dd and got a full image of the USB and then flashed that image on all the USBs.
### The Proof of Concept
After hosting multiple ICPC and OMI competitions, the team recognized that their experience with setting up a competitive programming contest environment was not unique. Many other universities faced similar challenges but lacked communication or collaboration on solutions.

3rd contest: During the third contest, some computers were using legacy BIOS, but the sticks prepared were only capable of booting on UEFI. Luckily enough there was enough UEFI computers to successfully boot a computer for all the teams. The performance of the system during the contest were good, it proved being a good a approach to be taken.
This realization led to the idea of creating a well-crafted, comprehensive solution to these challenges, leveraging the efforts of those who had already invested time in setting up contest arenas. However, before this could be achieved, a proof of concept was needed to demonstrate the feasibility of implementing the desired features. The main challenges included: *How to enable and disable software on-demand to comply with various competitions?*, *How to make the OS immutable so that all changes made by contestants can be erased while preserving persistence during competitions?*, and *How to provide data persistence for training camps while hiding and restricting access to contestants during contests?*

After this contest, some improvements were notable. It was needed to create a script to automatically update the wallpapers and clean all the persistent data left by the contestants on the USB keys. This led to an improved image with some scripts that connected to a server to download the current wallpaper and check for a time to clean all the contest data. This new image was called contestImage.
These ideas culminated in the project being selected as the graduation project for several students involved in competitive programming. Their goal was to prove that these scenarios were achievable by building a custom OS (distribution). These students were members of ESCOM's algorithmic club, whose official mascot is a *ferret*, or ***hurón*** in Spanish, which inspired the name huronOS.

4th contest: After re-flashing all the USB keys for the contest and just a day before the contest, it was informed that the server where the online judge was going to be hosted was different to the stated before. This was a big problem as the firewall was configured with a different address. The contest image had hardcoded the server address, so it was needed to rebuild that image and re-flash all USBs keys again. The contest was successful, but a lot of work had to be done with pressure because of this situation.
### The Current Project
After completing the graduation project, a working *Proof of Concept* was available. However, it still had several issues that needed to be addressed before it could be used in official competitions. Despite these challenges, at the beginning of 2022, several universities in Mexico City that were supposed to host the ICPC competition experienced a student strike, making it impossible for them to hold the contest. Another university stepped in to host the competition, but with the restriction of not modifying the computers and having access to them only on the day of the competition. In this scenario, huronOS proved to be the best available option.

The 4th date was important to determine that a lot of improvements were needed to cut the amount of time spent into configuring these systems, but the approach was right.
Following the successful contest, the team decided to release the first version, huronOS Queue 0.1 (alpha). Since then, the project has made significant progress and is now stable enough to be used by several organizations for their contests. However, huronOS still lacks certain features and characteristics common in other distributions, which is why it is still considered *alpha*.

The OMI: After all the ICPC, the university was selected to be the Mexican Olympiad of Informatics finals host. But the requirements, configurations and software for this contest were highly different than the ones prepared for the ICPC. This required again, rebuilding an image for changing the software, firewall, configs, etc.

The training camp: During the first winter training camp of the university, the contest image was used for the contests on the event, but it was not possible to use it during the learning sessions as it had a firewall and restrictions that was not allowing the participants to use internet, etc.

The Proof of Life
After a year of seeing all this issues, other communities were asked if they had similar issues during the organization of their competitions and they told they had them. So, Quetzalli asked herself, why not to build a definite solution to this. An OS capable of changing its behavior and be orchestrated from a server. A lot of specialized features were needed, like:

The OS should synchronize with a server to change its behavior, allowing to be orchestrated up to N instances of the OS remotely.
Build a live system that can boot from most hardware used at universities to host competitive programming events.
Enabling and disabling software remotely in a matter of seconds.
Changing its behavior in timed schedules depending on the event running (training camps, or contests, etc.).
Cleaning its own filesystem to restore its state depending on the event running while preserving the persistence of each event running.
Change the firewall configurations according to the specifications of the running event.
Change details like wallpaper, keyboard layout, language, bookmarks, etc.
This was the start of huronOS idea, a GNU/Linux distribution based on Debian and using the Linux-Live + Slax building tools as the base for building a proof of life with all the features needed and using this project as the final project for graduation.

In 2021 the project was approved to be used for the graduation of three students:

Abraham Omar
Bryan Enrique
Enya Quetzalli
During 2021 and 2022 the project was developed, and the first builds of huronOS came to the light, showing that it was possible to satisfy most of the needs for competitive programming contests.

The First Alpha
After the final project at the university, the huronOS project is continuing its path and bringing the PoL into an alpha state for development.
Currently, huronOS is used by several universities and is the official operating system for the Mexican Olympiad of Informatics. The project remains under active development, with the team aiming for the first official (non-alpha) release.

0 comments on commit fb55f1d

Please sign in to comment.