Adding version tag 0.3.1

versioned_docs/version-0.3.1/about/_category_.json

@@ -0,0 +1,8 @@
+{
+	"label": "About huronOS",
+	"position": 3,
+	"link": {
+		"type": "generated-index",
+		"description": "Learn about why huronOS exists and which problems it solves."
+	}
+}

versioned_docs/version-0.3.1/about/how-huronOS-started.md

@@ -0,0 +1,54 @@
+---
+sidebar_position: 1
+---
+
+TODO: Rewrite this text for new website
+
+# huronOS history
+huronOS starts its development by Enya Quetzalli in 2019 as a prototype of a distribution for competitive programming.
+
+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.
+
+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.
+
+2nd contest: On the second contest, the computers had a GNU/Linux distribution installed, but this was not complying with all the ICPC requirements.
+
+After all of this, Quetzalli proposed preparing live-USB systems to hold the contest. This was the seed for the development of huronOS.
+
+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.
+
+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.
+
+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.
+
+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 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.
+
+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.

versioned_docs/version-0.3.1/about/the-team.md

@@ -0,0 +1,34 @@
+---
+sidebar_position: 3
+---
+
+TODO: Review with the team
+
+# The huronOS team
+
+huronOS is a project that have had multiple contributions at different areas, some people is still contributing while others have stopped their contributions. We're always open to receive more people to onboard this project.
+
+### Contributors
+The contributors are persons that have wrote code, debugged the system, wrote documentation, reviewed architectural designs and/or mentor the development of the project.
+- Abraham Omar *\[inactive\]*  
+	Developer, ESCOM-IPN student.
+- Bryan Enrique *\[inactive\]*  
+	Debugger, ESCOM-IPN student.
+- Daniel Cerna *\[**active**\]*  
+	Developer, ITSUR grad.
+- Enya Quetzalli *\[**active**\] \[**lead**\]*  
+	Developer, ESCOM-IPN grad.
+- Jorge Cortés *\[**active**\]*  
+	Architect, ESCOM-IPN teacher.
+- Norman Saucedo *\[inactive\]*  
+	Mentorship, ESCOM-IPN teacher.
+
+### Testers
+The testers, are mainly site-manager that usually organize competitive programming contests and are willing to try huronOS's latest features on a frequent basis helping to flag issues with the distribution and determine the stability of each build.
+- Edgardo Franco *\[**active**\]*  
+	Site manager of ESCOM-IPN algorithms club, he usually sets the contest environments for either training contests, or ICPC official dates.
+- Daniel Cerna *\[**active**\]*  
+	Site manager of ITSUR CPCI club, having weekly training competitions and testing huronOS frequently.
+- Roberto Ríos *\[**active**\]*  
+	Site manager of CUCEI-UDG club, with frequent weekend competitions, they've been testing and using huronOS since the first alpha release.
+

versioned_docs/version-0.3.1/development/_category_.json

@@ -0,0 +1,8 @@
+{
+	"label": "Developing huronOS",
+	"position": 6,
+	"link": {
+		"type": "generated-index",
+		"description": "Learn how huronOS is developed, which technologies we use and and what standards do we follow."
+	}
+}

versioned_docs/version-0.3.1/development/development-standards.md

@@ -0,0 +1,42 @@
+---
+sidebar_position: 6
+---
+
+# Development Standards
+
+huronOS development requires writing code in different environments which can lead to the use of different editors like *nano*, *vi*, or GUI powered editors like *vscode*. In any case, we are still inclined to maintain certain quality standards in our codebase to keep collaboration simpler.
+
+## Editing Code
+We recommend you use vscode as the main editor as it provides you with several extensions that can help maintain the quality of code we're looking for at the codebase. Either way, there'll be a time when you'll have to use a terminal based editor, so we encourage you to polish your code as much as possible but don't forget to lint, format and check your code before committing it.
+
+## General Recommendations
+We have several general recommendations for developing huronOS. 
+
+### Spelling
+English is the main language for all the code and documentation in huronOS, this is intentional mainly due to globalization, this way most of the people involved is able to familiarize themselvers with the codebase; that's why it is important to keep our code with the best spelling and grammar possible, from the variable naming, to the code comments, documentation and overall resources. We recommend using VScode's [Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) extension, to catch all the spelling issues as you write. You can also use your own tooling but please keep this request in mind when doing so.
+
+## Shell Scripting
+
+### Formating
+All of the shell scripting styling follows the default configuration of [shfmt](https://github.com/mvdan/sh) which can be integrated with several code editors or executed from the terminal.
+We recommend the [VScode extension](https://marketplace.visualstudio.com/items?itemName=foxundermoon.shell-format) for *shfmt* which can be activated on save, making it easier to follow the standard.
+
+### Linting
+For shell scripting linting, we recommend using [Shellcheck](https://github.com/koalaman/shellcheck) which provides static code analysis to catch important bugs when writing shell scripts, which can be actually challenging to debug, track and find. If you're using VScode, there's a [ShellCheck extension](https://github.com/vscode-shellcheck/vscode-shellcheck) you can use.
+
+## Documentation
+Documentation is written on the [huronOS-build-tools](https://github.com/equetzal/huronOS-build-tools) repository, this keeps a relation between huronOS' versioning and its documentation. Documentation is built by using [Docusaurus](https://docusaurus.io), but the project is also the implementation of the [huronos.org](https://huronos.org) website, which its code is on the [huronOS-website](https://github.com/huronOS/huronOS-website) repository. The code submitted under the `huronOS-build-tools/docs` directory triggers a Github action to commit those changes to the website repo, and automatically deploy those changes using the following rules:
+- Pulls/Merges on the *unstable* branch, will commit on the website's *staging* branch and deploy to Github Pages a.k.a. [Staging](https://huronos.github.io/huronOS-website/).
+- Pulls/Merges on the *main* branch, will commit on the website's *main* branch but will not be deployed.
+- When releasing on Github, the action will checkout the release tag and commit those changes to the website's *stable* branch. This will create a new docusaurus documentation version and then will trigger a deploy on the [huronos.org](https://huronos.org) (production) website, which contains the documentation of all the official releases on huronOS-build-tools.
+
+### Markdown
+All the documentation is written in the markdown `.md` extension. We don't use `.mdx` (docusaurus markdown equivalent to `.jsx` files) as it minimizes compatibility with several markdown render tools and limit our documentation to few tools. There's no VScode extension for rendering the Docusaurus markdown style, but we'd advise using the *Hot Reload* feature.
+As an alternative to hot reload, you can use the [Github Markdown Renderer](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-preview-github-styles) VScode extension, but it will also render Docusaurus' specific metadata which might not be the ideal.
+
+### Docusaurus Hot Reload
+Please, clone the huronOS-website@staging and huronOS-build-tools@unstable repos at the same directory level, then run:
+```bash
+cd huronOS-website
+./dev-start.sh
+```

versioned_docs/version-0.3.1/development/documentation.md

@@ -0,0 +1,5 @@
+---
+sidebar_position: 4
+---
+
+TODO: Write doc

versioned_docs/version-0.3.1/development/how-to-contribute.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 1
+---
+
+TODO: Write doc
+
+# How can you help huronOS?

versioned_docs/version-0.3.1/development/how-to-create-a-build.md

@@ -0,0 +1,103 @@
+---
+sidebar_position: 8
+---
+
+# Building huronOS
+
+To build huronOS you'll need to follow several steps:
+
+1. **Install Debian:**  
+   First, install Debian 11.6 in a computer with a minimal installation setup. Make sure to not install **any** extra software mentioned on the installer, and do not setup extra users other than root. (if you do, erase them).
+
+2. **Get huronOS-build-tools**  
+   Clone this repo on the `/` root directory of your newly installed Debian.
+
+3. **Compile the huronOS kernel**  
+   huronOS needs a kernel that supports [AUFS](https://aufs.sf.net), so we need to replace the kernel. To do so, run as **root**:
+
+   ```bash
+   cd kernel-builder/
+   chmod +x build-kernel.sh
+   ./build-kernel.sh
+   ```
+
+4. **Build the base system**  
+   To build the base system (`01-base.hsl`) and the huronOS bootable skeleton filesystem, run as **root**:  
+
+   ```bash
+   chmod +x base-system/base.sh
+   ./base-system/base.sh
+   ```
+
+   Afterwards, you will find a similar structure to the following directory on `/tmp`:
+   ```bash
+   huronOS-build-tools-67321/ # Taking 67321 as an example, this will be different with each case. This value is the PID of the process.
+      ├── iso-data/
+      └── make-iso.sh
+   ```
+   By default, make-iso.sh will have a field `ISO_DATA=/tmp/huronOS-build-tools-67321/iso-data` and `ISO_OUTPUT=/tmp/huronOS-build-tools-67321/huronOS-b2023.00xx-amd64.iso`. If you're planing to move the directory, please make sure to update this routes accordingly.
+
+5. **Build the other system layers**
+
+   To build the rest of the layers, you'll need to install huronOS at a temporal USB drive, so go ahead and run:
+   ```bash
+   ./make-iso.sh # This step is necessary as it will calculate the checksums of the files
+   ./iso-data/install.sh # You just hit enter when prompt for directives URL and directives server IP
+   ```
+
+   After this, please boot up the installed system.
+   Once booted, make sure to have access to that repository and internet connection. **Please, consider that at this step, no persistence has been provided yet, so all the changes will be volatile**
+
+   Run, as **root**, the following commands to build the rest of the modules:
+
+   - `02-firmware.hsl`:
+     ```bash
+     cd software-modules/base/02-firmware/
+     chmod +x firmware.sh
+     ./firmware.sh
+     reboot
+     ```
+   - `03-budgie.hsl`:
+     ```bash
+     cd software-modules/base/03-budgie/
+     chmod +x budgie.sh
+     chmod +x setup-desktop.sh
+     chmod +x save.sh
+     ./budgie.sh
+     # Wait for the GUI to start
+     ./setup-desktop.sh # Run this as contestant
+     ./save.sh # Run this as root
+     reboot
+     ```
+   - `04-shared-libs.hsl`:
+     ```bash
+     cd software-modules/base/04-shared-libs/
+     chmod +x shared-libs.sh
+     ./shared-libs.sh
+     reboot
+     ```
+   - `05-custom.hsl`:
+     ```bash
+     cd software-modules/base/05-custom/
+     chmod +x custom.sh
+     ./custom.sh
+     reboot
+     ```
+
+
+   Next, return to the debian installation and plug the USB drive, then copy the modules on the `iso-data/huronOS/base/` directory.
+
+6. **Pack the current software**
+
+   After installing the base, the software to be used on competitions like ICPC or IOI will be required. The build scripts for each package are located in the directories
+
+   - [`internet`](./software-modules/internet/)
+   - [`langs`](./software-modules/langs/)
+   - [`programming`](./software-modules/programming/)
+   - [`tools`](./software-modules/tools/)
+
+   After finishing with all the software, copy the resultant `.hsm` files to the `iso-data/huronOS/software/` directory following the structure of the tree. Remember to reboot each time you create an `.hsm` module to prevent accumulating changes.
+
+7. **Create the ISO**
+
+   After completing the huronOS *iso-data* directory, you can run again the `make-iso.sh` to create the packed ISO and the Sha256 checksum.

versioned_docs/version-0.3.1/development/release-system.md

@@ -0,0 +1,7 @@
+---
+sidebar_position: 5
+---
+
+TODO: Write doc
+
+## Release System