¿Por qué AUR tiene que ser así?

Como odio cuando entro a Arch Wiki y dice que solo esta cómo AUR, es completamente odioso.

Sé que cuando instalo por ahí, tarda mucho en descargar. Y, luego, no lo actualizó nunca, ya que serían unas cuantas horas de tortura esperando a que actualicen. Por lo cuál, lo odio a los AUR, al saber que no los podré actualizar (si actualizó seguido desde pacman).

Quiero ver cómo es usar manim, solo está en AUR, por lo cuál, una vez terminado de descargar, no podré ver siguientes actualizaciones, a menos que sea posible actualizar un único paquete.

Esa el la ventaja de Archlinux, AUR es mantenido por los usuarios y si no simplemente no estaría ese paquete en la distro. Algo parecido pasa en Gentoo con los repositorios. Si bien existen los oficiales hay paquetes solo en repositorios de usuarios.

En mi caso, si realmente necesito un paquete, lo añado a mi repositorio local. Te invito a mantener ese paquete, así no tendrías problemas. Justamente esa es la idea de AUR, que los propios usuarios se realizan el mantenimiento de los paquetes.

Desde que uso chaotic-aur mi vida es mas simple, todo el software de AUR precompilado y sin usar helpers como yay, es lo mejor sin duda alguna.

Por si no sabes que es chaotic-aur, es un repositorio donde esta todo el software de AUR precompiliado y se descarga, desinstala y se actualiza desde el mismo pacman, es una maravilla.

1 me gusta

Podrías crear un script que actualice pacman y AUR al mismo tiempo.

1 me gusta

Está esta bastante interesante, así no tarda mil años en descargar y actualizar las cosas.

La razón por la que muchos de tus paquetes AUR tardan en instalar no es por la descarga, eso es irrelevante en la mayoría de los casos, lo que hace que el asunto tarde es que muchos de ellos compilan el código fuente directamente en tu máquina, eso si que puede llegar a tardar dependiendo de la potencia de tu procesador.

Si quieres actualizar solo un paquete del AUR es tan simple como

# suponiendo que usas paru
paru -S tu-paquete # como si fueses a instalarlo 

Si quieres comprobar si hay actualizaciones del AUR

paru -Qua

Si quieres evitar tener que compilar programas, verifica si es que existe una variante de tu paquete de interes con el sufijo -bin, seguro que eso si es un binario. Tambien evita las variantes con el sufijo -git, pues los cambios en desarrollo suelen ser muy frecuentes y tienden a romperse seguido. Ahora, que no lo tenga no significa que no sea un paquete con binarios ya disponibles, te recomiendo leer el PKGBUILD de cada paquete que quieras instalar para verificar que esta haciendo.

Usar chaotic-aur sirve… si el paquete que quieres lo tienen disponible (que parece no ser el caso para manim)

1 me gusta

Aur me dio tantos problemas en manjaro que ese fue uno de los motivos que me llevó a terminar usando debían.

Pero es una exageración los tiempos, pacman, que es el gestor principal de Arch, es lo mejor. AUR tarda demasiado.

No tanto en descargar, sino es un horror cuando veo los gcc y g++, y se que va a tardar.

Aunque el código en C no tarda mucho, Linux (kernel, no es el sistema GNU/Linux, cómo vienen haciendo en varias publicaciones) tiene 3.000.000 lineas de código segun dicen, y tarda 40 minutos en compilar.

Pero, la mayoría usan C++, que tarda un 500% más. Por ejemplo, godot (motor de juegos) tarda horas, mientras que linux unos minutos…

Eso es porque ese paquete no te proporciona el compilado, sino el código fuente y lo compila, como Gentoo pero sin optimización. Busca la versión binaria de ese paquete (-bin) o no vas a tener escapatoria.

Para eso esta chaotic-aur

y el caso de como digo @amaterasu tiene un -git que no esta en chaotic-aur? eso es la mayor funcionalidad que le veo al programar tu propio script, lo deja en segundo plano y le puede limitar recursos de la PC con docker o otra manera que no conozca para limitar recursos.

Un ejemplo del horror de c++ para compila en comparación con c:
Tomemos primero en c:

#include <stdio.h>
int main(int argc,char**argv)
{
	printf("Hola Mundo!!!\n");
	return 0;
}

Su compilación:

time gcc main.c -o a

real	0m0,059s
user	0m0,039s
sys	0m0,019s

Ahora c++:

#include <iostream>
int main(int argc,const char**argv)
{
	std::cout << "Hola Mundo!!!" << std::endl;
	return 0;
}

Su salida:

time g++ main.cpp -o b

real	0m0,563s
user	0m0,516s
sys	0m0,041s

Cómo se ve, son solo unos hola mundo, con un 500% de diferencia en sus compilaciones…

Con la flag -static:

time gcc main.c -o a -static

real	0m0,118s
user	0m0,081s
sys	0m0,035s
time g++ main.cpp -o b -static

real	0m1,072s
user	0m0,603s
sys	0m0,168s

La diferencia es del 1000% !!!

Y, hay de la memoria (el a es con c, y el b con c++)

ll -h
total 3,2M
-rwxr-xr-x 1 marco marco 813K nov 13 23:02 a
-rwxr-xr-x 1 marco marco 2,4M nov 13 23:02 b
-rw-r--r-- 1 marco marco   92 nov 13 22:55 main.c
-rw-r--r-- 1 marco marco  115 nov 13 22:55 main.cpp

En caso de que sean dinámicos…

ldd a
	linux-vdso.so.1 (0x00007f60d38b6000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f60d3600000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f60d38b8000)
ldd b
	linux-vdso.so.1 (0x00007f1bd905c000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1bd8c00000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f1bd8ef4000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f1bd8ec7000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f1bd8800000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f1bd905e000)

Conclusión, c++ es muchísimo más complicado y lento que c. Cuando un programa está en c++, y solo está en AUR, ahí si que te enojas. Es horrible. Y, la mayoría de los progamas están en c++ en lugar de c (el qué uso yo).

2 Me gusta

Ni pruebes rust. Te va a dar un infarto.

2 Me gusta

No, le deja de circular la sangre del susto

Rust no parece tan lento en compilar como c++…

Mismo ejemplo, pero con rust:

fn main(){
    println!("¡Hola, Mundo!");
}

Compilación

time rustc main.rs

real	0m0,126s
user	0m0,070s
sys	0m0,056s

Tamaño del ejecutable

ll -h
total 448K
-rwxr-xr-x 1 marco marco 437K nov 13 23:46 main
-rw-r--r-- 1 marco marco   45 nov 13 23:41 main.rs

Dependencias

ldd main
	linux-vdso.so.1 (0x00007f8b894cd000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f8b893f1000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f8b89000000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f8b894cf000)

En Estático tiene mejores resultados que c

time rustc -C target-feature=+crt-static main.rs

real	0m0,228s
user	0m0,122s
sys	0m0,106s

Aunque pesa más

ll -h
total 1,5M
-rwxr-xr-x 1 marco marco 1,5M nov 13 23:50 main
-rw-r--r-- 1 marco marco   45 nov 13 23:41 main.rs
drwxr-xr-x 3 marco marco 4,0K nov 13 23:41 old

Observa el tamaño, 1.5M. Ahora que lo he notado. ¿Que has hecho para que tu binario en c y c++ sea tan grande? es 20 veces mas grande que los estáticos que he compilado.

En GNU/Linux se mete toda la biblioteca del estandard de C o C++ dentro del ejecutable al hacerlo estático.

También, es que tengo gcc y g++ version 15.

Eso iba a decir, al usar compiladores como TCC o Zapcc (un derivado de Clang) mejoran bastante la velocidad y me imagino que el peso de los ejecutables tambien pero ahí no estoy seguro.

1 me gusta

Eso es lo que me sorprende, aunque mi Gentoo Linux es musl. ¿Esa será la causa de la diferencia?

Copiando el mismo código.

No estáticos.

-rwxr-xr-x 15K Nov 14 19:30 a
-rwxr-xr-x 16K Nov 14 19:30 b

Estáticos

-rwxr-xr-x   21K Nov 14 19:33 a
-rwxr-xr-x  1.4M Nov 14 19:33 b