Re: El manifiesto y los principios Agiles - gratuito - 1342286177
Porfavor, márquenlo como spam!! Es muy rápido http://lists.debian.org/debian-user-spanish/2012/07/msg00433.html -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABr7qmRC7V9Vb9R0ppR96uyQSPckY2-k6ejiWGsFFMeOob7o=g...@mail.gmail.com
Re: Extraño comportamiento con ssh y firefox
El Sat, 14 Jul 2012 22:33:15 +0200, fernando sainz escribió: El día 14 de julio de 2012 22:26, Camaleón noela...@gmail.com escribió: (...) Camaleón, acabo de salir y entrar con otro usuario distinto y efectivamente no me pasa. Ni idea de por qué se produce esto, pero desconcierta un poco. Entonces ya sé qué puede ser. Firefox es (o era al menos) muy puñetero con eso de tener dos instancias abiertas con el mismo usuario/mismo perfil. Mira a ver si lanzándolo con firefox -no-remote te permite hacer lo que buscas. Funciona, pero no deja de extrañarme este comportamiento. ¿Si estoy en una sesión remota como es que ejecuta el comando en la local ? Supongo que será porque como dicen ellos mismos¹, cuando inicias Firefox con una instancia ya en ejecución, la nueva instancia se acopla a la inicial. De hecho, si ejecuto Firefox en mi equipo y luego intento abrir una segunda instancia en local ejecutada desde el mismo usuario (firefox -no-remote) no me deja, me dice que ya hay una instancia abierta y que debo cerrarla. En cambio, si lo ejecuto desde otro usuario (root) con «gksu firefox -no-remote» se abre sin problemas. Y si se ejecuta desde una sesión ssh pues pasará lo mismo. ¹http://kb.mozillazine.org/Opening_a_new_instance_of_your_Mozilla_application_with_another_profile Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtu9dn$83b$1...@dough.gmane.org
Re: OT: Problema FTP Debian
El Sat, 14 Jul 2012 19:03:30 -0300, Juan escribió: El día 14 de julio de 2012 07:03, Camaleón noela...@gmail.com escribió: Vale, pero leyendo el asunto no creo que sea OT :-) ok, pensé que al no ser algo específico de debian iba como OT. ProFTP es un programa que está en Debian, en los repos habituales. Me parece que nos estamos volviendo un poco paranoicos en esta lista :-P Que te falle la conexión en remoto pero no en local parece indicar que el problema no está en la configuración del servicio. Sugerencias: - No utilices el navegador para acceder, prueba a conectarte con un cliente FTP. Me da error tambien, dice que se pasa a modo PASV y que recibe una respuesta incorrecta El error lo debes de tener igual, eso está claro, lo que me interesa es que pongas el comando que ejecutas y la salida que te da. La ventaja de usar un cliente ftp (p. ej., ftp) es que permite opciones de depuración (-v y -d) que en este caso te podrían ser de ayuda. - Revisa el registro del servidor FTP, debes de tener más datos ahí. Este es un GRAN problema para mi. Soy bastante autodidacta, pero no encuentro mucha info sobre como entender los logs, los trato de leer, pero a mi, no me dicen nada, no se ver los problemas que reportan. Quiero aprender a hacerlo, pero no logro dar con el sitio donde aprender. Sigo en la busqueda. Los mensajes de error los irás interpretando con el tiempo y la experiencia. Súbelos a algún lado (www.pastebin.com) para que podamos ver qué te dice (ojo, omite datos sensibles en caso de haberlos). Más info sobre los registros de ProFTP aquí: http://www.proftpd.org/docs/howto/Logging.html - Prueba con la dirección IP en lugar del nombre del dominio (ftp remote_ip:2821) en caso de tengas una IP fija. No tengo ip fija, pero busque en cualesmiip.com la ip publica y da el mismo error Si no tienes IP la cosa se complica un pelín porque tendrás que usar algún sistema de DNS dinámico y la IP que te aparezca en este caso importa menos porque puede no estar actualizada en la base de datos del servicio y redireccionarte a otro cliente. No es fiable. - Revisa la configuración del router: si usas dyndns que todo esté correcto, si usas NAT revisa los valores de la redirección de puertos, posible apertura del puerto en el cortafuegos en caso de tenerlo...). El router tien el firewall desactivado, al menos hasta terminar de hacer funcionar esto, despues me pondre a ver eso para darle mas seguridad. NO uso dyndns, uso freedns.afraid.com, me gusta más y me funciona todo lo demas, la pagina web, phpsysinfo, phpmyadmin, etc El servicio que uses es irrelevante pero tienes que tenerlo bien configurado, obviamente. Y recuerda que algunos modems tienen problemas para redireccionar los servicios a la red local cuando sales desde ellos, es decir, que pruebes a conectarte al servidor FTP desde una conexión distinta que no salga por tu modem/router. Puedes decirle a algún amigo que lo pruebe, por ejemplo. Lo bueno de DynDNS es que tiene documentación interesante para los problemas más comunes, echa un vistazo a ver si alguna de las cosas que mencionan te da alguna idea: http://www.dyndnscommunity.com/questions/722/ddns-and-ftp-access.html Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtuaq2$83b$2...@dough.gmane.org
Re: Extraño comportamiento con ssh y firefox
El día 15 de julio de 2012 13:26, Camaleón noela...@gmail.com escribió: El Sat, 14 Jul 2012 22:33:15 +0200, fernando sainz escribió: El día 14 de julio de 2012 22:26, Camaleón noela...@gmail.com escribió: (...) Camaleón, acabo de salir y entrar con otro usuario distinto y efectivamente no me pasa. Ni idea de por qué se produce esto, pero desconcierta un poco. Entonces ya sé qué puede ser. Firefox es (o era al menos) muy puñetero con eso de tener dos instancias abiertas con el mismo usuario/mismo perfil. Mira a ver si lanzándolo con firefox -no-remote te permite hacer lo que buscas. Funciona, pero no deja de extrañarme este comportamiento. ¿Si estoy en una sesión remota como es que ejecuta el comando en la local ? Supongo que será porque como dicen ellos mismos¹, cuando inicias Firefox con una instancia ya en ejecución, la nueva instancia se acopla a la inicial. Ya, pero no olvidemos que estoy en otra maquina... :-) De hecho, si ejecuto Firefox en mi equipo y luego intento abrir una segunda instancia en local ejecutada desde el mismo usuario (firefox -no-remote) no me deja, me dice que ya hay una instancia abierta y que debo cerrarla. En cambio, si lo ejecuto desde otro usuario (root) con «gksu firefox -no-remote» se abre sin problemas. Y si se ejecuta desde una sesión ssh pues pasará lo mismo. ¹http://kb.mozillazine.org/Opening_a_new_instance_of_your_Mozilla_application_with_another_profile Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtu9dn$83b$1...@dough.gmane.org -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGw=rhjkarj9_stpdpvebr+v5jjabwec+qmz4pavqfcyn8n...@mail.gmail.com
Re: Extraño comportamiento con ssh y firefox
El Sun, 15 Jul 2012 14:18:05 +0200, fernando sainz escribió: El día 15 de julio de 2012 13:26, Camaleón noela...@gmail.com escribió: (...) Funciona, pero no deja de extrañarme este comportamiento. ¿Si estoy en una sesión remota como es que ejecuta el comando en la local ? Supongo que será porque como dicen ellos mismos¹, cuando inicias Firefox con una instancia ya en ejecución, la nueva instancia se acopla a la inicial. Ya, pero no olvidemos que estoy en otra maquina... :-) Sí pero no. Cuando inicias una sesión gráfica vía SSH los procesos se comparten, supongo que para ahorrar recursos, ancho de banda... y entiendo que es lo que sucede con Firefox que no es precisamente una aplicación de las que se puedan considerar como ligeritas :-P Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtufqk$83b$4...@dough.gmane.org
Re: Nvidia binary blob and libcairo2 1.10+
2012/7/15 hvw59601 hvw59...@care2.com: Dan Serban wrote: For those unaware, running wheezy or squeeze + backports while using the Nvidia binary blob (and in some cases nouveau) drawing _anything_ in X is painful, it can take seconds to respond to a mouse click, or minimizing/maximizing a window. Scrolling speed is horrendous as well. For the months that I've experienced this problem, I've been waiting for Debian to step up and either find a workaround or fix the issue. The issue from what I understand stems from libcairo enabling features that the Nvidia driver blob cannot cope with. The bug is reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616308 Reading through that bug report, it seems that this has been an issue for some time, a patch is provided and I have successfully upgraded to my own package which includes the patch. My question is: Am I alone here? snip No you are not. I pinned libcairo, easier than patching it. Hugo I pinned libcairo too, to squeeze-backports version. -- LARGA VIDA Y PODEROSA. Blog de Haldrik -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadydv-cj8xgsjntx9bmrp5qsxavc2k8_bb_tvbjhuxqja6k...@mail.gmail.com
