Uranium4Linux

 Debido a la reciente decisión de Software Libre de aumentar el plazo los últimos commits de Uranium también serán validos. Ahora mismo el desarrollo de Uranium se está basando en :   Dar soporte las nuevas funcionalidades que Rinth está añadiendo como Resourcepacks, Plugins, Modpacks. Mejorar el código para que funcione de forma mas eficiente.    Debido a que han sido las recuperaciones de la universidad no he tenido todo el tiempo que me gustaría para Uranium pero ahora que ya he acabado puedo volver a dedicarle más parte de mi tiempo. MORE DEVELOPMENT IS REQUIRED

Aunque ya haya llegado el fin del plazo para las contribuciones Uranium4Linux va a seguir actualizándose ya que necesita añadir soporte a las nuevas funcionalidades de ModRinth, mejorar el rendimiento y solucionar problemas en el código. Uranium4Linux se creo con el propósito de facilitar y acelerar la instalación de modpacks para minecraft pero con el tiempo se han ido añadiendo funcionalidades como soporte para requests, resourcepacks, hacer modpacks a partir de instalaciones de minecraft etc. MORE DEVELOPMENT IS REQUIRED.

 Uraium4Linux ahora da soporte a la instalación de modspack con formato curse. La velocidad con la que Uranium4Linux es capaz de instalar los modspacks sigue siendo muy superior a GD Launcher o Twitch Launcher. Esto era de esperar porque la parte mas costosa siempre es hacer las requests y descargar los mods y ya sabíamos que Uranium es blazingly fast haciendo las requests así que ahora que solo había que copiar los archivos de configuración no seria mucho mas lento. También he resuelto un par de problemillas con respecto a las requests asíncronas y es que probando Uranium en ordenadores con hardware más modesto (Intel Atom 1 núcleo 2 hilos) me di cuenta que al crear tantas threads como requests tenga que hacer esto puede ser un inconveniente ya que puede saturar la capacidad de la CPU por lo tanto he añadido una nueva flag que limita las threads que puede crear Uranium. ./Uranium4Linux -d -f ./MiModpack.zip -r /minecraft/root -t 16   Con la flag -t limitamos el número de threads que

Después de finalmente implementar url_maker para Curse, un curse_requester y toda la parafernalia requerida para testear el rendimiento que Uranium4Linux puede proporcionar a la hora de descargar mods llega el momento de la verdad. Rust es un lenguaje que destaca por su velocidad ya que al ser compilado y tener un 0 abstraction cost puede ofrecer mucho rendimiento. Yo sabia que Uranium4Linux sería blazingly fast y realmente esperaba resultados mejores que la competencia (GD Launcher [código abierto], Twitch Launcher [Privativo af]). Aquí muestro el resultado de estos dos últimos Launchers: A la izquierda GD Launcher con 52s y a la derecha Twitch Launcher con 145s https://github.com/gorilla-devs/GDLauncher Ahora vamos a ver el rendimiento que puede ofrecernos Uranium4Linux a la hora de descargar un paquete de 296 Mods con un peso de 500Mb aproximadamente. cargo run --release  2.79s user 2.00s system 59% cpu 8.056 total   8 segundos !!! No podia creermelo, Uranium4Linux es capaz de desca

Hasta ahora Uranium4Linux solo soportaba el repositorio de mods RINTH pero ayer mientras "bicheaba" otros proyectos libres encontré lo siguiente:  https://github.com/gorilla-devs/GDLauncher/blob/master/napi/src/lib.rs No me lo creía! Parecía la pieza de código que me faltaba para conseguir que Uranium4Linux sacará los hashes de los archivos y que la api de CURSE los admitiese, así que como buen programador hice lo que tenia que hacer.    Ctrl+C, Ctrl+V   Después de copiar y pegar en mi código y sacarle el hash a un archivo parecía que daba un resultado correcto, lo puse en https://reqbin.com/ (una pagina web que permite hacer requests) y efectivamente el resultado era correcto, la api me devolvía una respuesta 200 con todo el contenido del mod.   MURMUR 2  El algoritmo que utiliza Curse para sacar el hash a los archivos es Murmur2. No lo había escuchado en mi vida, y he tenido algunos problemas para implementarlo ya que he intentado utilizar otras librerías que no sean las q

Async Pool Debido a que Uranium4Linux toma ventaja de la programación asíncrona es necesario una pool de tareas para que este pueda funcionar de forma eficiente. El principal problema de las task es que no se puede saber el tiempo que va a tomar ejecutarlas por lo tanto necesitamos de algo que pueda comprobar si la task esta lista y, en caso de que lo este, guardar el resultado o aplicar alguna función. Para conseguir esto he diseñado una estructura tal que: pub struct AsyncPool<T> {     request_pool: Vec<JoinHandle<T>>,     items: usize,     not_done_request: Vec<usize>,     ordered_requests: HashMap<usize, T> }   La idea original de la AsyncPool era que el orden en el que los resultados son devueltos a partir de task no estuviera garantizado. Es decir, si añado un vector con las tasks [1, 2, 3, 4] el vector con los resultados no