# Nix(OS) GSoC Ideas

## i18n for Nix

Make nix messages and texts translatable.

This has far reaching benefits in making the software more accessible for non-anglocentric regions.

In addition, some local governments require software to work in their language before consideration. Without this, nix and the whole ecosystem is a non-starter.

Quick eye-catching keywords:

* **Accessibility** (worldwide)

## TAGS scheduling in Hydra

*Link to paper missing (if there was one)*

The basic idea is to "unfairly" schedule everything the same way, cancel builds running for longer than an arbitrary amount, then re-schedule them on beefier builders, for longer, for a couple of steps.

What this does is that it gives all quick running, or trivial, builds a first chance to run in a highly parallelized manner. Tasks that are not trivial are bumped into a next "try".

Longer, but still relatively trivial builds will succeed in a second round, longer builds will get re-scheduled and so on.

What this achieves is that the scheduling doesn't need to know about the scope of the builds. Long non-trivial builds will not continue to run in an environment under contention where they will conflict with the load of many other builds.

Example rounds:

| timeout | parallel jobs | machine type |
|------------|---------------|--------------|
| 30 seconds | 48 | 48 core cpu |
| 5 mins | 16 | 48 core cpu |
| 30 mins | 2 | 64 core cpu |
| 10 hours | 1 | 64 core cpu |

In such a setup:

* A `writeScript` job would likely run under 30s in that first round.
* A longer, but still trivial, build like U-Boot is likely to finish either in the second or third round
* A much more complex build like webkit would end up in the last round

In a naïve way, it would look like this adds a flat 35.5 minutes cost to the longer builds.

That would be the case in isolation, but if those longer builds are fighting for resources on a machine, the added build time can balloon up quickly. This is currently worked around by manually marking those jobs as "big-parallel", which may leave behind some jobs that would benefit from it.

Additionally, with the appropriate metrics, the intent is to adjust the rounds the builds are going through until they are optimized.