Mostrando entradas con la etiqueta emule. Mostrar todas las entradas
Mostrando entradas con la etiqueta emule. Mostrar todas las entradas

martes, 15 de junio de 2021

Problemas con emule a través de wine en Fedora 34

Desde mi inicio en Linux, que si no recuerdo mal fue con Ubuntu 7.10, tuve que cambiar de emule a amule. Sin embargo, en julio de 2018, como señalaba aquí, amule empezó a congelar el sistema por consumo excesivo de memoria y CPU. En ese momento me volví al emule de toda la vida a través de wine. Y eso fue hasta la última actualización de wine (wine 6.10) y kernel (5.12.9-300.fc34.x86_64). En ese momento, emule empezó a utilizar el sistema sin control y se congelaba —emule, no el sistema; ventaja de que estaba en wine—, así que me he cambiado de nuevo a amule. Funciona razonablemente, al contrario de lo que había pasado en 2018, y tiene algunas ventajas. Primero, estoy en una aplicación de Linux; segundo, puedo utilizar un comando que me permite reiniciar automáticamente amule cuando salta, lo que pasa frecuentemente, sin que me tenga que preocupar. ¿Cómo se hace? Véase esta entrada.

 

Otra cosa que he realizado aprovechando la situación fue cambiar la estructura del ordenador añadiendo un disco nuevo para toda la parte ed2k. La idea es evitar una escritura continua sobre un disco ssd (/home), que hará que dure poco tiempo, por lo que instalé un hdd NAS (WD Red Plus) para ed2k, colocando Incoming y Temp en ese disco, liberando el disco /home (SSDV-NAND SSD 860 QVO SATA 6Gb/s de 2 TB). Debemos tener en cuenta que nuestros discos de trabajo a estas alturas son ssd o m2, en todo caso discos sólidos que no viven mucho tiempo si los tenemos grabando de manera continua, como pasa con ed2k. Por si hay dudas sobre esto, ya sabéis que los discos ssd de los mineros que minan por almacenamiento, como es el caso del minado de Chia coin, se estropean muy rápidamente y las compañías fabricantes no cambian los discos que se hayan sometido a minado. Y esa es la razón de que los discos hayan subido de esa manera de precio, situación que parece se está recuperando.

Para terminar, parece ser que podemos volver a amule y debemos cuidar nuestros discos utilizando para ed2k discos magnéticos (mientras existan).

domingo, 29 de marzo de 2020

Puertos para el intercambio de pares. ed2k y el paso del tiempo



Sí, a mi me ha gustado siempre el intercambio de pares. Bueno, siempre no, solo desde que nació, sobre el año 2000, y nos permitió intercambiar material sin depender del protocolo ftp que usábamos antes, en descargas accidentales en fragmentos de 49MB, simplemente para descubrir que te faltaba uno y todo el tiempo usado —modems de 32kbps, con suerte 4Kb/s— no había servido para nada; sí, batallitas de los viejos. Personalmente, mi favorito por aquel entonces era overnet, ya que incluía intercambio descentralizado basado ya en kademlia y no eras esclavo de servidores que a veces desaparecían; vamos, igual que ahora, por ejemplo, este enero pasado. Bien, desde hace mucho mucho tiempo, desde que se pudieron controlar, tenía configurados los puertos siempre de la misma manera, controlados por el cortafuegos y el router. Ahora que no los voy a usar digamos que eran TCP 5521 y 5524 y UDP 4242 y siempre habían funcionado de maravilla y seguía lo de no cambies lo que funciona. Sin embargo desde hace un tiempo, yo me he dado cuenta desde este enero, los servidores no aceptan estos puertos y el intercambio era fundamentalmente por kademlia, y no alcanzaba las prestaciones que tenía antes. En un momento libre, de esos que tenemos ahora en nuestro confinamiento, he probado diferentes variaciones y siguiendo algunas recomendaciones que he visto en la red, los he elegido en la banda que va desde 60000 a 65000, y sí, todo ha vuelto a la normalidad. Para antiguos como yo que siguen las costumbres antiguas, a veces hay que revisarlas y mejorarlas. Habrá que cambiar los puertos dedicados al ed2k a superiores a 60000.

PD. ¿Qué cliente ed2k uso ahora? Después de muchos años de usar amule, debido al uso salvaje que hace de la memoria RAM, estoy usando el emule habitual a través de WINE, y va de fábula; bueno, ahora que he cambiado los puertos.

$ wine '/ruta/hasta/emule.exe'

y listo.

PDD. No, no insistáis. No me gusta el torrent. No tengo nada más que decir

viernes, 20 de julio de 2018

Linux, ¿amule o emule en WINE?

Sí, si hacemos intercambio de pares, ¿qué instalamos, amule o emule? Ciertamente lo más sencillo es instalar amule; simplemente:

su -c 'dnf install amule'

y listo, siempre que hayamos activado el repositorio RPM Fusion Free. Sin embargo los últimos días del mes de junio a a principios de julio la versión disponible de amule generaba un consumo de memoria y CPU que acababa colapsando el sistema, al menos en Fedora, que era mi caso (la actualización ya disponible ha corregido ese problema). Ademas, amule, al menos en mi caso, tiene otros problemas; en general si tiene actividad de descarga se cuelga en cualquier momento y hay que reiniciarla. Esto requiere para un funcionamiento adecuado que lancemos amule desde un script que se ocupe de detectar la caída de amule y lo vuelva a llamar (véase aquí). Por estas razones decidí probar el funcionamiento de emule. Por supuesto necesitamos tener instalado WINE y podemos directamente a través de él instalar la versión exe de emule (descarga aquí). No se necesita nada más y los ficheros de configuración y almacén son compatibles entre amule y emule (simplemente moverlos entre directorios). En el caso de que no estéis muy a gusto con uno, se puede usar el otro sin problemas.
Y como muestra un botón: