powered-by-linuxmint

 

Pequeña reseña sobre esta distro. Experimentar con un cambio de distro de escritorio como es Linux Mint en su sabor basado en debian testing (LMDE) es excitante. Ubuntu funciona bien, cada vez menos, pero en general va muy bien. El marrón lo odio y Unity más con lo cual le dí una oportunidad al cambio. Me sumo sin duda a los que se refieren a Linux Mint como un “Ubuntu mejorado” o un “Ubuntu hecho correctamente”.

Seguir leyendo…

Ya son 3 máquinas migradas a 64bits sin novedad.

He estado tuneando los sistemas por aquí y por allá, adaptando anteriores y optimizadas configuraciones al renovado sistema y ahora la cosa marcha bien, muy bien. Lo que más tiempo que me ha llevado en los equipos con entorno de escritorio, que en realidad no ha sido tanto, fue la optimización de Pulseaudio y los plugins del navegador.

Tras un tiempo de uso he sustituido el navegador que originalmente instalé Swiftfox para tener mis plugins de Flash(32bits) y Java(32bits) funcionando ya que las fuentes no las configuraba bien y el aspecto en general dejaba que desear.

El sustituto quasi-perfecto (está en inglés) hasta el momento ha sido Swiftweasel. Este nuevo proyecto paralelo a firefox de navegador “sin marca” tiene dos versiones, una de 64 y otra de 32 bits, originalmente tiene un repositorio para Ubuntu aunque yo lo he acoplado en mi Debian sin ningún problema, ahora mis fuentes se ven bien y tengo FLASH y JAVA. Una anécdota importante es un problema que me daba instalando extensiones (add-ons), daba un error -213 que me mandaba a revisar la consola de errores, la instalación de extensiones era totalmente fallida, tras investigar encontré un post que decía que HABÍA QUE BORRAR EL ARCHIVO extensions.rdf dentro del perfil del navegador, así lo hice y todo se resolvió.

Para instalarlo hay que añadir la línea al archivo sources.list:

deb http://download.tuxfamily.org/swiftweasel hardy multiverse

y luego instalar el swiftweasel32-athlon64 con:

apt-get install swiftweasel32-athlon64
(por ej. aunque yo uso aptitude)

64bits running

Los 64 bits han llegado a mis 2 máquinas principales, el ordenata de escritorio y el server ambas con Debian testing/SID.

Siempre fui reticente a este cambio de arquitectura ya que como buen experimentador ya instalé versiones anteriores de AMD64 en sus comienzos siempre con resultados catastróficos, en su mayor parte por la falta de software compilado para 64bits y el tema de tener gran parte del sistema en 32bits y ya se sabe que mezclar no es bueno. Hoy por hoy el problema está mas o menos resuelto.

Para los Windowseros las opciones quedan reducidas a güindous XP 64 bits, quizá el más maduro, luego tenemos el elenco de los poca VISTA, que parece que con el SP1 la cosa se ha vuelto menos inestable y próximamente habrá una versión del güindous Server 2008 64. Todos estos paquetes suelen tener un precio directamente proporcional a los recursos de hardware que se pierden usándolos.

Comienzo:

El proceso comienza con una copia de seguridad exhaustiva de los directorios /etc y los /home de los usuarios que albergan las configuraciones de las aplicaciones, así no hay que pensar en la reinstalación, la mayoría de las aplicaciones conservan archivos de configuración similares para ambas arquitecturas y luego con un copy paste quedan configuradas. También me hago con una lista de los paquetes instalados con “dpkg –get-selections > dpkglist” para luego ir replicando el sistema.

Seguimos. La instalación desde el CD netinstall de DEBIAN amd64 va fluida excepto algún problema con las nuevas particiones en XFS (siempre quise probarlo). La instalación personalizada se lleva a cabo sin problemas y en el server se me instala LILO como cargador de arranque ya que GRUB se lleva mal con XFS y el debian installer dice que me olvide de poner GRUB, esto me pasó en una máquina, en la otra hice una partición /boot en ext3 y todo fue rodado, vale, tiene pase.

usb-memory-bomb

Primeros problemas:

Con el sistema en reconstrucción llegaron los primeros problemas, tras instalar el entorno gráfico y paquetes varios observé que el plugin de java no funcionaba en el Iceweasel (firefox). Tras googlear y hacer mis propios apaños vi que era imposible habilitarlo, la solución derivó por la instalación de Swiftfox que es un paquete que agrega al sistema un navegador en 32Bits (beta) que está basado en el motor de Firefox 3. Salimos del paso aunque el navegador está un poco cogido con pinzas.

El tema del multimedia, otro miedo de antaño, me encuentro que en el repositorio de Marillat hay un paquete que es w64codecs que me resuleve el tema de los codecs de Windows de un plumazo. Otro pequeño paso resuelto. Observo, al igual que en UBUNTU, que han incluido el paquete “Tracker” y procedo a instalarlo.

El paquete “Tracker” es un indizador masivo de archivos del equipo, trabaja con una base de metadatos que se actualiza con cualquier cambio, es una gran ayuda a la hora de buscar cualquier cosa, rápido y eficaz, me gusta y ya lo he usado unas cuantas veces.

Conclusión:

El sistema funciona con más frescura y las particiones en XFS vuelan literalmente, allí metí el sistema, los volúmenes de almacenamiento son ext3. Ahora mismo todo funciona pero ha sido una operación digna de alguien con ganas de complicarse la vida y de que manera.

Quiero probar ese rendimiento precisamente con los proyectos del BOINC a los cuales estoy suscrito que son Rosseta y SETI, veremos esas stats de aquí a unas semanas 😀


sanitarium:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
stepping : 3
cpu MHz : 2812.962
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 5630.14
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
stepping : 3
cpu MHz : 2812.962
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 5625.96
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc


sanitarium:~$ uname -a
Linux sanitarium 2.6.24-1-amd64 #1 SMP Fri Apr 18 23:08:22 UTC 2008 x86_64 GNU/Linux

truckshockwave

24

Nov

por Señor N

mldonkey new-logo

Tras un largo periplo por Amule, Azureus y otros sabores de la red bittorrent he vuelto a unos orígenes con fundamento: MlDonkey.

– Puertos:

Tras un ajuste en mi firewall-iptables he conseguido no solo una ID alta sino que también sirva para algo y descargue bien. Tenemos definidos los puertos 9001 TCP/UDP + 9005 UDP para la red Donkey, los 9002 TCP/UDP para kademlia (ayuda mucho en búsqueda de fuentes) y Bittorrent 10001 TCP/UDP (no aparece en la imagen).

iptables puertos

servidores con hi id

He descubierto una de las grandes desventajas que posee aMule que es no poder descargar archivos mayores de 4 GB, de ningún modo. Hoy por hoy esa desventaja ha sido crucial para hacer que me esmerara en la configuración de Mldonkey para ofrecerme un rendimiento óptimo si no perfecto. Atrás quedaron frustraciones del pasado ya que con un poco de configuración he llegado a un resultado en 4 días más que notable con archivos de pocas fuentes.

Una de las piedras angulares en el rendimiento han sido dos simples configuraciones referentes a los límites de descarga y subida y la desactivación de redes innecesarias.

– Ajustes Subida/bajada (download/upload):

En lo referente a la configuración del primer apartado me he limitado a dejarlo así tras una serie de pruebas de rendimiento de red, leyendo en algunos foros que contiene un bug en las últimas versiones en las cuales hay que determinarle el doble del valor para algunas variables para que rindan con la mitad de lo configurado, por ejemplo, en mi rate de subida configuré 200 Kb para que realmente rinda a 100 Kb de subida, soy generoso claro. La descarga a 0, o sea, sin límite.

opciones de subida y bajada

– Activar redes necesarias:

El tema de activación y desactivación de redes fui práctico y dejé las que realmente voy a utilizar y quité las que convierten al servidor en un monstruo amasa recursos y paquetes de red entre múltiples redes de P2P. Conseguí los resultados que buscaba con la siguiente configuración:

opciones de seleccion de red

Con todo esto afinado y alguna configuración menor dentro de los archivos donkey.ini y downloads.ini he conseguido lo que pienso que será una duradera amistad entre mi y el P2P con cliente P2P como servicio y control web para el manejo quasi total.

Estadísticas en poco tiempo

27

May

por Señor N

Debido a una serie de restructuraciones forzosas debido a unas actualizaciones de la rama SID de Debian me vi obligado a darle otra oportunidad a mi viejo amigo MLdonkey.¿Realmente ha mejorado el sistema de gestión de redes y puede ofrecerme resultados equiparables a otros programas?

Mldonkey: mldonkey logo

Sitio web oficial: mldonkey

Hace casi 2 años que no probaba mldonkey, tenía ganas. Eliminé cualquier rastro de programa de descargas p2p en mi sistema y procedí a instalar mldonkey-server y mldonkey-gui. Tras una instalación sencilla y rápida se inició una configuración post-install ncurses donde me preguntaba parámetros básicos de configuración de la conexión y usuario contraseña para el acceso del usuario administrador (!). Todo bien.

Inicié el demonio en segundo plano y rápidamente me fui a revisar los archivos de configuración. Ahí es donde todo me resultó familiar, downloads.ini bittorrent.ini donkey.ini … y los directorios temporal y de llegada. Comprobé los permisos para que desde mi red LAN pudiera acceder al “core” del programa ya bien desde telnet (dificil manejo), desde el interface gráfico cliente o desde la web.

Retoqué velocidades de subida y bajada y cambié el número de conexión de servidor para la red Donkey dejándolo en solo 1 (por defecto se conecta a 3) y actualicé la lista de servers, me costó mucho que algunos valores se “fijaran” en los archivos ini de configuración, él programa, al parar-iniciar el demonio se cargama mis retoques y volvía a la configuración por defecto en las diversas redes, los puertos sobre todo me fastidiaban, el número de conexiones máximas. Acabé guardando los ini’s buenos en un directorio por si acaso. Afiné el firewall y a funcionar.

Mi primera impresión al abrir el gui fue buena, todo cargaba y accedí al control del core de manera sencilla y cómoda. Realicé unas búsquedas sencillas de archivos de vídeo y música, al principio puse cosas que ya había encontrado antes, luego, al ver la manera “especial” de devolver resultados como una mezcla entre que no había conectado al servidor y que no había entendido la cadena que había puesto en el buscador, al final empezó a arrojar algunos resultados, pocos. Procedí a buscar cadenas de texto de descarga masivas como juegos y películas y los resultados fueron mejor, la disponibilidad me pareció poca en muchos archivos.

Seguí firme con el voto de confianza. Opté por poner los enlaces ed2k diréctamente desde las páginas webs donde sabía que estaban las cosas que quería descargar. Ahí si que aparecieron los archivos a descargar. Puse 5 archivos, 3 populares y 3 menos populares.

Las fuentes de enlace se sumaban y se reiniciaban a 0 como en loop, no acababa de ver color azul en los archivos de manera contínua. Verifiqué si había desconexiones en la red o me había dejado algo en el firewall, nada, todo OK.

Tres días dejé transcurrir con varias descargas en marcha conectado a DonkeyServer nº1.

Amule-daemon: amule logo

Sitio web oficial: Amule

En otra prueba posterior instalé el amule-daemon animado al modo de funcionamiento que me encanta de mldonkey. Realicé los ajustes necesarios para límites de descarga y conecté a DonkeyServer nº1 (el que estadísticamente me funciona mejor).
Los resultados fueron tipo mldonkey, el gui que al final conseguí conectar al “core” de amule me ofreció poca estabilidad en sí mismo (me dió errores y se cerró en varias plataformas y equipos) al final pude hacer unas búsquedas simples y encargué los mismos archivos de prueba.

Tres días más.

Amule:

Mi venerado amule fué la última prueba, y definitiva. Este amule en cuestión lo tengo funcionando en una sesión de X disponible por VNC. Lo que quiero decir es que el amule se ejecuta de manera gráfica y plena y su control lo realizo manualmente. El mismo modus operandi. Configuración, puertos, conexiones, firewall, búsquedas, conexión a DonkeyServer nº1 y 3 días mediante.


Conclusión:

Mldonkey:

800 Mb. descargados y un funcionamiento ligero pero irregular. Muy muy configurable.

Amule-daemon:

1’2 Gb. descargados y un funcionamiento menos ligero pero algo irregular también. El gui muy mejorable en estabilidad.

Amule:

3,4 Gb. descargados, carga media en memoria y recursos. Búsquedas abundantes y rápidas, muy estable en las descargas y en el mantenimiento de las fuentes en los archivos.

No acabo de entender cual es la razón por la cual mldonkey, que es mi preferido en la manera de funcionar y manejar, no llega a las cotas de eficacia dentro de la red edonkey como otros programas como amule. Eso sí, dentro del equipo, ni se nota que está corriendo y el número de opciones a configurar es glorioso, no se si tendré algún día tiempo para hacer un tunning PROFUNDO a las config de mldonkey para que me sea más satisfactorio, pero de momento casi por defecto…

¡Amule WINS!