Debian testing más testing que n unca. [ Antes: Re: sobre nuevos errores]
Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Gracias y saludos, amaury viera hdez wrote: Amigos, ayer instale debian lenny y hoy sid, sucede que cuando se reconfigura el xorg ya en ninguna distribucion aparece la parte de seleccionar el controlador de video, la resolucion de pantalla y muchas mas opciones, ahora, lo que hice en los dos casos ayer y hoy fue copiar mi antiguo fichero /etc/X11/xorg.conf para mi nuevo sistema y em ambos casos cuando reinicio el gdm me queda mi resolucion de pantalla deseada que es la 1024x768, ahora cuando esto sucede ya me quedo sin aceso a las terminales virtuales(CTRL+ALT+F1,F2,F3,F4,F5,F6). Otra cosa yo soy el muchacho que pregunto ademas previamente el problema del alsa que no se me carga al iniciar el sistema y me dieron como consejo que tratara de incrustarle el modulo al kernel con el module-assistant, muchas gracias por el consejo pero no me funciono, y no solo eso sino que ademas no me funciona en sid tampoco, no probe ayer con testing si, pero el hardware de la maquina era bien distinto al mio, de hecho, en ese hardware nunca me ha sucedido, en este siempre. Bueno saludos y espero puedan darme algunas ideas a a mis interrogantes. Amaury. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Gracias y saludos, amaury viera hdez wrote: Amigos, ayer instale debian lenny y hoy sid, sucede que cuando se reconfigura el xorg ya en ninguna distribucion aparece la parte de seleccionar el controlador de video, la resolucion de pantalla y muchas mas opciones, ahora, lo que hice en los dos casos ayer y hoy fue copiar mi antiguo fichero /etc/X11/xorg.conf para mi nuevo sistema y em ambos casos cuando reinicio el gdm me queda mi resolucion de pantalla deseada que es la 1024x768, ahora cuando esto sucede ya me quedo sin aceso a las terminales virtuales(CTRL+ALT+F1,F2,F3,F4,F5,F6). Otra cosa yo soy el muchacho que pregunto ademas previamente el problema del alsa que no se me carga al iniciar el sistema y me dieron como consejo que tratara de incrustarle el modulo al kernel con el module-assistant, muchas gracias por el consejo pero no me funciono, y no solo eso sino que ademas no me funciona en sid tampoco, no probe ayer con testing si, pero el hardware de la maquina era bien distinto al mio, de hecho, en ese hardware nunca me ha sucedido, en este siempre. Bueno saludos y espero puedan darme algunas ideas a a mis interrogantes. Amaury. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Creo que no termino de entender este mail... si usas testing y/o sid ya sabes lo que estás asumiendo. Si usas stable ya sabes que no vas a tener ningún tipo de problema a costa de no tener las últimas versiones del software que pudiera ir saliendo. Decir que Debian pueda desaperecer por estar usando testing y tener dependencias rotas me parece, sinceramente, ridículo. Pido disculpas de antemano si alguien cree que el tono empleado no es el adecuado, pero es que estoy ya cansado de escuchar a la gente diciendo que Debian terminará desapareciendo por Ubuntu y tonterías de similar calibre. Un saludo, Abraham Pérez
Re: Debian testing má s testing que nunca. [ Antes: Re: sobre nuevos errores]
On Wed, Jul 02, 2008 at 09:25:03AM +0200, José Luis Triviño wrote: Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Pues oye, yo llevo usando con normalidad desde hace años sid en varias máquinas (en otras uso stable, claro) y no he notado ese aumento de *inestabilidad* que comentas respecto a otras épocas. En cualquier caso, el aumento en la cantidad de software empaquetado hace que pudiera considerarse como normal un aumento en los *problemillas* en testing y unstable, claro. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Con todos mis respetos, lo que planteas me parece una auténtica chorrada. Sinceramente, creo que, en general, el trabajo de toda la gente involucrada en Debian es magnífico y tenemos una gran distribución para mucho tiempo. Si quieres utilizar testing/unstable estás asumiendo que habrá errores que pueden tardar más o menos tiempo en ser corregidos. No veo la pérdida de calidad a la que haces referencia por ningún lado, la verdad. Un saludo y un poco menos de alarmismo, por favor. E. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes : Re: sobre nuevos errores]
Abraham Pérez wrote: El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Creo que no termino de entender este mail... si usas testing y/o sid ya sabes lo que estás asumiendo. Si usas stable ya sabes que no vas a tener ningún tipo de problema a costa de no tener las últimas versiones del software que pudiera ir saliendo. Decir que Debian pueda desaperecer por estar usando testing y tener dependencias rotas me parece, sinceramente, ridículo. Pido disculpas de antemano si alguien cree que el tono empleado no es el adecuado, pero es que estoy ya cansado de escuchar a la gente diciendo que Debian terminará desapareciendo por Ubuntu y tonterías de similar calibre. Esta bien! Lo preguntaré de otra forma para que hasta tú puedas entenderlo: ¿Crees que debian testing es más inestable en la actualidad que hace unos años? Yo creo que si. Y creo que esto puede estar afectando a la calidad de Debian. No creo que sea ridículo plantearselo cuando todos sabemos que la vesrión estable de debian en muchos casos no ofrece la versión del programa que necesitamos. Yo vengo desde hace bastante tiempo utilizando la versión testing y nunca tuve ningún problema. Instalaba todo tan bien como en la estable y tenía las versiones de programas que me interesaban. De unos meses a la actualidad me encuentro que esos programas no están en la estable y no instalan correctamente en la inestable. Luego creo que puede estar bajando la calidad de la distribución. Y eso es lo que comento aquí. No creo que sea un comentario ridículo. Si en otras distribuciones te encuentras la versión que necesitas del programa integrada en la distribución de forma más estable eso podría perjudicar a Debian. Y no digo nada necesariamente de Ubuntu. Que parece que te ha tocado la vena sensible. Saludos, P.D. En posteriores respuestas a una lista procura hacer el ridículo evitando palabras como ridículo o tonterías. El intercambio de opiniones razonado nunca es ridículo ni tonto. Sino constructivo. Tenga quien tenga la razón y se llegue a la conclusión que se llegue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 10:48, José Luis Triviño [EMAIL PROTECTED] escribió: Abraham Pérez wrote: El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. No a todos nos gustan los entornos supergráficos por ejemplo y preferimos herramientas sencillas. (Lo malo conocido) Saludos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Regla de iptables
Hola lista, Tengo un problemilla con iptables. A ver si me podéis echar una mano, pero no al cuello ;) Tengo un pc que hace de firewall (iptables) funcionando perfectamente para mis necesidades claro. Tiene dos tarjetas de red, una que esta enchufada al router wireless de internet (eth0) y la otra que va a un switch que este a su vez enchufa a otros pc's (eth1). Dentro de la red local (eth1) hay una impresora en red que me gustaría compartir con las dos interfaces de tal forma que la gente que se conecta al router wireless, puedan acceder perfectamente a esa impresora que esta dentro de la red local. He estado probando varias reglas con forward, forward con nat... pero ninguna me ha funcionado. Sabéis si esto que quiero hacer es posible hacerlo? Me podéis arrojar algo de luz? Un saludo y muchas gracias por vuestra ayuda. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
No he probado ultimamente las versiones inestables o de pruebas pero el etch me anda bastante bien, de echo ya deje de lado en mi laptop el ubuntu e instalado manualmente las últimas actualizaciones de software que yo utilizo mas uno que otro agregado a los repositorios, como opinión según mi experiencia en debian no desaparecera ni aunque tenga un millon de bugs importantes por un echo de estabilidad y versatilidad que nos dan estos sistemas (unix, linux, hurde) pero si deberiamos tener en cuenta estos mas que como una advertencia como una experiencia, el solo hecho que ya nos demos cuenta de estos y el crear el reporte del bug ya es un gran avance a nivel de comunidad preocupemosnos cuando hagan oidos sordos a los requerimientos , comparto lo mencionado por otro compañero sobre el aumento de problemillas comoalgo dependiente del aumento de software y tambien comparto que tienen todo el derecho a aparecer en versiones de pruebas pues para eso son, pues en mi pc puede fallar pero quizas no en otro sistema en vez de pelear dediquemosnos a seguir avanzando, dejesmole la peleeas a los contratos, extorsiones y mala compras de privativos un saludo y a seguir DISCUTIENDO no a insultarse... para eso tenemos otro SO w32 que ni él merece tales cosa El mié, 02-07-2008 a las 11:19 +0200, fernando sainz escribió: El día 2 de julio de 2008 10:48, José Luis Triviño [EMAIL PROTECTED] escribió: Abraham Pérez wrote: El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. No a todos nos gustan los entornos supergráficos por ejemplo y preferimos herramientas sencillas. (Lo malo conocido) Saludos.
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
Abraham Pérez wrote: El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Gracias y saludos, amaury viera hdez wrote: Amigos, ayer instale debian lenny y hoy sid, sucede que cuando se reconfigura el xorg ya en ninguna distribucion aparece la parte de seleccionar el controlador de video, la resolucion de pantalla y muchas mas opciones, ahora, lo que hice en los dos casos ayer y hoy fue copiar mi antiguo fichero /etc/X11/xorg.conf para mi nuevo sistema y em ambos casos cuando reinicio el gdm me queda mi resolucion de pantalla deseada que es la 1024x768, ahora cuando esto sucede ya me quedo sin aceso a las terminales virtuales(CTRL+ALT+F1,F2,F3,F4,F5,F6). Otra cosa yo soy el muchacho que pregunto ademas previamente el problema del alsa que no se me carga al iniciar el sistema y me dieron como consejo que tratara de incrustarle el modulo al kernel con el module-assistant, muchas gracias por el consejo pero no me funciono, y no solo eso sino que ademas no me funciona en sid tampoco, no probe ayer con testing si, pero el hardware de la maquina era bien distinto al mio, de hecho, en ese hardware nunca me ha sucedido, en este siempre. Bueno saludos y espero puedan darme algunas ideas a a mis interrogantes. Amaury. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Creo que no termino de entender este mail... si usas testing y/o sid ya sabes lo que estás asumiendo. Si usas stable ya sabes que no vas a tener ningún tipo de problema a costa de no tener las últimas versiones del software que pudiera ir saliendo. Decir que Debian pueda desaperecer por estar usando testing y tener dependencias rotas me parece, sinceramente, ridículo. Pido disculpas de antemano si alguien cree que el tono empleado no es el adecuado, pero es que estoy ya cansado de escuchar a la gente diciendo que Debian terminará desapareciendo por Ubuntu y tonterías de similar calibre. Un saludo, Abraham Pérez Yo hasta ahora no he tenido mayores problemas (a Dios Gracias!) Salu2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
Emilio J. Padron escribió: On Wed, Jul 02, 2008 at 09:25:03AM +0200, José Luis Triviño wrote: Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Pues oye, yo llevo usando con normalidad desde hace años sid en varias máquinas (en otras uso stable, claro) y no he notado ese aumento de *inestabilidad* que comentas respecto a otras épocas. En cualquier caso, el aumento en la cantidad de software empaquetado hace que pudiera considerarse como normal un aumento en los *problemillas* en testing y unstable, claro. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Con todos mis respetos, lo que planteas me parece una auténtica chorrada. Sinceramente, creo que, en general, el trabajo de toda la gente involucrada en Debian es magnífico y tenemos una gran distribución para mucho tiempo. Si quieres utilizar testing/unstable estás asumiendo que habrá errores que pueden tardar más o menos tiempo en ser corregidos. No veo la pérdida de calidad a la que haces referencia por ningún lado, la verdad. Un saludo y un poco menos de alarmismo, por favor. E. Comparto absolutamente la ultima respuesta . Para mi debian es la mejor distribucion y me parece que por algo estan en testing , ya que logicamente deberia tener no uno si no varios errores , por algo esta la rama testing . Baja la estable y listo , por favor dejemonos de reportar bolucedes absurdas . atte Gustavo Bs. As. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
Lo ideal sería que en testing todo fuera más o menos bien ya que se supone que será la próxima versión de debian pero claro, es lógico que haya algún error. Eso no quita para estar de acuerdo con el creador original de este hilo en que últimamente veo más fallos que antes, aunque no creo que sea nada escandaloso si que pueden ser fallos que molestan más o que hacen más daño, y que a lo mejor por eso se notan más, como lo que me pasa a mí con el ratón en las X que hace doble click cuando le sale de los webs, por ejemplo. Cierto es que tenemos sid que es la rama inestable por delante y delante de esa está experimental y que lo deseable es que testing estuviera bastante pulida y casi lista para el horno pero bueno, supongo que es el precio que hay que pagar por tener los paquetes más actualizados, todo va más rápido y es más dificil dejarlo libre de bugs. Lo que si es seguro que la gente que tiene estable está bien contenta porque es como una roca, y eso es lo verdaderamente importante en Debian. Se que no he aportado mucho, pero es mi opinión. Un saludo
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 13:58, Daniel [EMAIL PROTECTED] escribió: Lo ideal sería que en testing todo fuera más o menos bien ya que se supone que será la próxima versión de debian pero claro, es lógico que haya algún error. Eso no quita para estar de acuerdo con el creador original de este hilo en que últimamente veo más fallos que antes, aunque no creo que sea nada escandaloso si que pueden ser fallos que molestan más o que hacen más daño, y que a lo mejor por eso se notan más, como lo que me pasa a mí con el ratón en las X que hace doble click cuando le sale de los webs, por ejemplo. Cierto es que tenemos sid que es la rama inestable por delante y delante de esa está experimental y que lo deseable es que testing estuviera bastante pulida y casi lista para el horno pero bueno, supongo que es el precio que hay que pagar por tener los paquetes más actualizados, todo va más rápido y es más dificil dejarlo libre de bugs. Lo que si es seguro que la gente que tiene estable está bien contenta porque es como una roca, y eso es lo verdaderamente importante en Debian. Se que no he aportado mucho, pero es mi opinión. Un saludo Pues no sé el resto, pero a mi me parece que aportas lo fundamental: recordar que hay muchas ramas a elegir en Debian y que si uno quiere una roca, que esté en stable. No sé, a mi me parece algo muy muy obvio aunque hay quien no opina igual. De hecho yo entiendo que con la variedad que hay de distribuciones en la actualidad, si yo no estoy contento con lo que tengo, puedo cambiarme sin problemas... no?
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El mié, 02-07-2008 a las 11:19 +0200, fernando sainz escribió: [...] Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. Que buena idea, podríamos sugerirles a los debian developers que creen una rama que se congele en cierto punto y a la que sólo se le agreguen parches de seguridad o de bugs graves. Esta rama tendría que pasar primero por un proceso de pruebas para que al momento de congelarla tenga la menor cantidad posible de bugs. Me pregunto como podrían llamarla... -- Gabriel Parrondo GNU/Linux User #404138 GnuPG Public Key ID: BED7BF43 JID: [EMAIL PROTECTED] The only difference between theory and practice is that, in theory, there's no difference between theory and practice. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 14:28, Gabriel Parrondo [EMAIL PROTECTED] escribió: El mié, 02-07-2008 a las 11:19 +0200, fernando sainz escribió: [...] Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. Que buena idea, podríamos sugerirles a los debian developers que creen una rama que se congele en cierto punto y a la que sólo se le agreguen parches de seguridad o de bugs graves. Esta rama tendría que pasar primero por un proceso de pruebas para que al momento de congelarla tenga la menor cantidad posible de bugs. Me pregunto como podrían llamarla... Creo que no me has entendido bien, se supone que Lenny es una version para digamos integrar los programas que ya han sido probados en sid. Lo que no entiendo es que se quiten programas que están en estable, si no hay version nueva se podría dejar la vieja, a eso me refiero. A eso y a esa sensación de no saber si tu programa favorito va a seguir siendo parte de Debian (Siempre me ha dado mucha rabia que hayan quitado programas que usaba y me gustaban...) Saludos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 14:42, fernando sainz [EMAIL PROTECTED] escribió: El día 2 de julio de 2008 14:28, Gabriel Parrondo [EMAIL PROTECTED] escribió: El mié, 02-07-2008 a las 11:19 +0200, fernando sainz escribió: [...] Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. Que buena idea, podríamos sugerirles a los debian developers que creen una rama que se congele en cierto punto y a la que sólo se le agreguen parches de seguridad o de bugs graves. Esta rama tendría que pasar primero por un proceso de pruebas para que al momento de congelarla tenga la menor cantidad posible de bugs. Me pregunto como podrían llamarla... Creo que no me has entendido bien, se supone que Lenny es una version para digamos integrar los programas que ya han sido probados en sid. Lo que no entiendo es que se quiten programas que están en estable, si no hay version nueva se podría dejar la vieja, a eso me refiero. A eso y a esa sensación de no saber si tu programa favorito va a seguir siendo parte de Debian (Siempre me ha dado mucha rabia que hayan quitado programas que usaba y me gustaban...) Saludos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Digo yo, que siempre están los fuentes... no?
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 14:46, Abraham Pérez [EMAIL PROTECTED] escribió: El día 2 de julio de 2008 14:42, fernando sainz [EMAIL PROTECTED] escribió: El día 2 de julio de 2008 14:28, Gabriel Parrondo [EMAIL PROTECTED] escribió: El mié, 02-07-2008 a las 11:19 +0200, fernando sainz escribió: [...] Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. Que buena idea, podríamos sugerirles a los debian developers que creen una rama que se congele en cierto punto y a la que sólo se le agreguen parches de seguridad o de bugs graves. Esta rama tendría que pasar primero por un proceso de pruebas para que al momento de congelarla tenga la menor cantidad posible de bugs. Me pregunto como podrían llamarla... Creo que no me has entendido bien, se supone que Lenny es una version para digamos integrar los programas que ya han sido probados en sid. Lo que no entiendo es que se quiten programas que están en estable, si no hay version nueva se podría dejar la vieja, a eso me refiero. A eso y a esa sensación de no saber si tu programa favorito va a seguir siendo parte de Debian (Siempre me ha dado mucha rabia que hayan quitado programas que usaba y me gustaban...) Saludos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Digo yo, que siempre están los fuentes... no? Si, pero estamos hablando de Debian. ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El mié, 02-07-2008 a las 14:42 +0200, fernando sainz escribió: El día 2 de julio de 2008 14:28, Gabriel Parrondo [EMAIL PROTECTED] escribió: El mié, 02-07-2008 a las 11:19 +0200, fernando sainz escribió: [...] Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. Que buena idea, podríamos sugerirles a los debian developers que creen una rama que se congele en cierto punto y a la que sólo se le agreguen parches de seguridad o de bugs graves. Esta rama tendría que pasar primero por un proceso de pruebas para que al momento de congelarla tenga la menor cantidad posible de bugs. Me pregunto como podrían llamarla... Creo que no me has entendido bien, se supone que Lenny es una version para digamos integrar los programas que ya han sido probados en sid. Lo que no entiendo es que se quiten programas que están en estable, si no hay version nueva se podría dejar la vieja, a eso me refiero. A eso y a esa sensación de no saber si tu programa favorito va a seguir siendo parte de Debian (Siempre me ha dado mucha rabia que hayan quitado programas que usaba y me gustaban...) Los programas se quitan por algún motivo. Generalmente porque son abandonware, porque no siguen las DFSG o la Debian Policy, o simplemente porque son inmantenibles (muchos bugs que upstream se niega a corregir, código muy sucio, etc. En estos casos suele aparecer un fork). En el caso de doc++ por ejemplo, el mantenedor del paquete de debian no lo había actualizado en 3 años y medio y no había habido una versión de upstream desde 2002 [0]. No es a debian que se lo ocurrió que está obsoleto, está obsoleto y fue reemplazado por doxygen. Del sitio de doxygen[1]: Thanks go to: Malte Zöckler and Roland Wunderling, authors of DOC++. The first version of doxygen borrowed some code of an old version of DOC++. Although I have rewritten practically all code since then, DOC++ has still given me a good start in writing doxygen. [0]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477400 [1]http://www.stack.nl/~dimitri/doxygen/ -- Gabriel Parrondo GNU/Linux User #404138 GnuPG Public Key ID: BED7BF43 JID: [EMAIL PROTECTED] The only difference between theory and practice is that, in theory, there's no difference between theory and practice. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Debian testing más testing que nun ca. [ Antes: Re: sobre nuevos errores]
- fernando sainz [EMAIL PROTECTED] wrote: Yo en general veo a Lenny muy estable, aunque he estado un par de semanas sin compiz, he sobrevivido... :-) (Es la primera vez que he instalado algo distinto de estable) Lo que no me gusta demasiado es que Debian incluye muchos paquetes nuevos pero deja de soportar algunos que uno lleva usando toda la vida y claro, tienes que buscarle substituto y cambiar cosas Por ejemplo yo estoy documentando código con doc++ y me he encontrado con que lo han sacado de Lenny. (He visto que hay otros paquetes similares y puede que mas potentes, pero me supone un trastorno ) Tal vez habría que buscar estabilidad por este camino también, tratar de mantener los paquetes a lo largo del tiempo aunque a alguien le puedan parecer obsoletos. No a todos nos gustan los entornos supergráficos por ejemplo y preferimos herramientas sencillas. (Lo malo conocido) Generalmente cuando un software/paquete es retirado de la Distribución es por motivos de abandono por parte del mantenedor, se le dejó de dar soporte por parte del ó los desarrolladores, existió algún problema en el proyecto relacionado con este paquete. En fin, pocas veces he visto injustos abandonos de paquetes en Debian, aunque no niego que me ha dolido uno que otra; pero como les comentaba generalmente es por razones que no se pueden controlar. Creo que no se les puede pedir más de lo que dan nuestros queridos desarrolladores que inviertes su tiempo libre en lineas de código o documentación para que podamos disfrutar hoy de lo que tenemos. Saludos cordiales Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Regla de iptables
Emilio wrote: Hola lista, Tengo un problemilla con iptables. A ver si me podéis echar una mano, pero no al cuello ;) Tengo un pc que hace de firewall (iptables) funcionando perfectamente para mis necesidades claro. Tiene dos tarjetas de red, una que esta enchufada al router wireless de internet (eth0) y la otra que va a un switch que este a su vez enchufa a otros pc's (eth1). Dentro de la red local (eth1) hay una impresora en red que me gustaría compartir con las dos interfaces de tal forma que la gente que se conecta al router wireless, puedan acceder perfectamente a esa impresora que esta dentro de la red local. He estado probando varias reglas con forward, forward con nat... pero ninguna me ha funcionado. Sabéis si esto que quiero hacer es posible hacerlo? Me podéis arrojar algo de luz? Un saludo y muchas gracias por vuestra ayuda. Emilio, porque no empiezas por postear tu script de iptables? Por otro lado, suponiendo que la IP de la Impresora de Red sea 192.168.0.1, podrías probar con algo como: iptables -A INPUT -p tcp -i eth0 -d 192.168.0.1 -j ACCEPT Saludos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Analizar log de dansguardian ON LINE y disparar evento
Hola Lista. Es posible analizar ON LINE los logs de dansguardian y ante algún evento (por ejemplo la visita de alguna página indevida) disparar un script? Este tipo de controles puede generar recargas en el servidor? Muchas Gracias. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing má s testing que nunca. [ Antes: Re: sobre nuevos errores]
On Wed, Jul 02, 2008 at 02:42:23PM +0200, fernando sainz wrote: El día 2 de julio de 2008 14:28, Gabriel Parrondo [EMAIL PROTECTED] escribió: [...] Creo que no me has entendido bien, se supone que Lenny es una version para digamos integrar los programas que ya han sido probados en sid. Lo que no entiendo es que se quiten programas que están en estable, si no hay version nueva se podría dejar la vieja, a eso me refiero. A eso y a esa sensación de no saber si tu programa favorito va a seguir siendo parte de Debian (Siempre me ha dado mucha rabia que hayan quitado programas que usaba y me gustaban...) En debian los paquetes que tienen mantenedor activo generalmente se mantienen en la distribución. En el caso de doc++, me parece que el mismo mantenedor hace rato que estaba tratando de deshacerse del paquete, pues había solicitado su remoción. La remoción se concretó cuando ya no quedaron dependencias reversas en el repositorio. Si a uno realmente le interesa un paquete, debería informarse de como le va mediante los múltiples medios que provee debian. Si a nadie le interesa mantener el paquete, por último puede uno mismo dedicarse a mantenerlo si el interés en salvarlo es mucho o si se le tiene mucho cariño. Lamentarse no conduce a nada, hay que poner trabajo y energía, esa es la manera debian. -- Blu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Regla de iptables
Emilio escreveu: Hola lista, Tengo un problemilla con iptables. A ver si me podéis echar una mano, pero no al cuello ;) Tengo un pc que hace de firewall (iptables) funcionando perfectamente para mis necesidades claro. Tiene dos tarjetas de red, una que esta enchufada al router wireless de internet (eth0) y la otra que va a un switch que este a su vez enchufa a otros pc's (eth1). Dentro de la red local (eth1) hay una impresora en red que me gustaría compartir con las dos interfaces de tal forma que la gente que se conecta al router wireless, puedan acceder perfectamente a esa impresora que esta dentro de la red local. He estado probando varias reglas con forward, forward con nat... pero ninguna me ha funcionado. Sabéis si esto que quiero hacer es posible hacerlo? Me podéis arrojar algo de luz? Un saludo y muchas gracias por vuestra ayuda. Pero claro que es posible, siempre y cuando tu impresora esté siendo compartidad a través de protocolo TCP/IP. En el mensaje no aclaraste este punto, entonces hay que preguntarte: ¿como compartís esta impresora? ¿Samba/Windows? ¿Unix/CUPS? Las reglas se configuran como si fueran para un servicio de tu red. Al estilo si el datagrama llega en la interfaz eth0 y tiene como destino la ip del sistema que controla la impresora, entonces hago forward. Saludos. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Regla de iptables
El mié, 02-07-2008 a las 10:25 -0300, ciracusa escribió: Emilio wrote: Hola lista, Tengo un problemilla con iptables. A ver si me podéis echar una mano, pero no al cuello ;) Tengo un pc que hace de firewall (iptables) funcionando perfectamente para mis necesidades claro. Tiene dos tarjetas de red, una que esta enchufada al router wireless de internet (eth0) y la otra que va a un switch que este a su vez enchufa a otros pc's (eth1). Dentro de la red local (eth1) hay una impresora en red que me gustaría compartir con las dos interfaces de tal forma que la gente que se conecta al router wireless, puedan acceder perfectamente a esa impresora que esta dentro de la red local. He estado probando varias reglas con forward, forward con nat... pero ninguna me ha funcionado. Sabéis si esto que quiero hacer es posible hacerlo? Me podéis arrojar algo de luz? Un saludo y muchas gracias por vuestra ayuda. Emilio, porque no empiezas por postear tu script de iptables? Por otro lado, suponiendo que la IP de la Impresora de Red sea 192.168.0.1, podrías probar con algo como: iptables -A INPUT -p tcp -i eth0 -d 192.168.0.1 -j ACCEPT Saludos. Hola, Muchas gracias por contestar con tanta rapidez. Cuando llegue a casa pruebo lo que me comentas y, os posteo el script de iptables. Para Miguel Da Silva: La impresora no esta enchufada a ningún equipo, es decir, esta tiene su propia tarjeta de red con lo que es como si fuera un equipo mas de la red. Muchas gracias de nuevo. Un saludo. Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
grep script
Hola lista Estoy con un script y tengo problemillas con el siguiente comando: NO FUNCIONA: sed -e s/^\/dev\/[s,h]d[a-z][1-9]/`blkid -s UUID \`/ archivo.datos En este caso no se intercambia por el valor que deberia, en teoria sda1 hda1... pero si añado un echo antes del blkid si intercambia por sda1 hda1... FUNCIONA: sed -e s/^\/dev\/[s,h]d[a-z][1-9]/`echo blkid -s UUID \`/ fstab.old no entiendo el porque de este comportamiento. He buscado en google y he visto otros ejemplos con date echo pero nada claro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
Pues me sumo a lo que dice Jose, esta mas testing que nunca, habra que esperar hasta fin de año para que se regularize la situacion... El día 2 de julio de 2008 3:25, José Luis Triviño [EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Gracias y saludos, amaury viera hdez wrote: Amigos, ayer instale debian lenny y hoy sid, sucede que cuando se reconfigura el xorg ya en ninguna distribucion aparece la parte de seleccionar el controlador de video, la resolucion de pantalla y muchas mas opciones, ahora, lo que hice en los dos casos ayer y hoy fue copiar mi antiguo fichero /etc/X11/xorg.conf para mi nuevo sistema y em ambos casos cuando reinicio el gdm me queda mi resolucion de pantalla deseada que es la 1024x768, ahora cuando esto sucede ya me quedo sin aceso a las terminales virtuales(CTRL+ALT+F1,F2,F3,F4,F5,F6). Otra cosa yo soy el muchacho que pregunto ademas previamente el problema del alsa que no se me carga al iniciar el sistema y me dieron como consejo que tratara de incrustarle el modulo al kernel con el module-assistant, muchas gracias por el consejo pero no me funciono, y no solo eso sino que ademas no me funciona en sid tampoco, no probe ayer con testing si, pero el hardware de la maquina era bien distinto al mio, de hecho, en ese hardware nunca me ha sucedido, en este siempre. Bueno saludos y espero puedan darme algunas ideas a a mis interrogantes. Amaury. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Off topic - Programa en C para manejar puerto serial
Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico ( http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø
Alternativa a phpBB
Buenas tardes. Me gustaría conocer vuestras opiniones acerca de algún software para crear un foro alternativo a phpBB. Descarto este de primeras debido a su largo historial de vulnerabilidades que me llevan a no darme ninguna confianza. Saludos. smime.p7s Description: S/MIME cryptographic signature
Re: Control de Tráfico en Linux - Traffic Shapping
Yo te recomiendo Quagga para QoS :) Pedro 2008/7/1 Federico Alberto Sayd [EMAIL PROTECTED]: Kevin Zambrano escribió: tq escribió: Hola compañeros. Dado un equipo con Debian Lenny haciendo las veces de proxy/router, y actualmente corriendo Squid/Dansguardian perfectamente, que me recomiendan ir leyendo para implementar control de tráfico: - delay pools - tc - ambos? No conozco delay pools por lo que te recomiendo iproute (utilidades ip y tc). Con tc puedes hacer mucho. http://www.linuxfoundation.org/en/Net:Iproute2_examples http://ornellas.apanela.com/dokuwiki/pub:firewall_and_adv_routing Te recomiendo iproute2 y un programita llamado htb.init que te gestiona el control del ancho de banda. Saludos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- p3dRø
RE: Averiguar /dev
Hola, he instalado usbmount y configuré el usbmount.conf con las
indicaciones que me dabais. Tengo el tail lanzado para ver que ocurre cuando
conecto y desconecto el usb, pero me sigue sin funcionar. No se donde me lo
ha montado, así que para probar copio un fichero a /media/usb /media/usb0
/media/usb1 pero ninguno es el disco usb porque al quitarlo y ponerlo en un
pc Windoze no veo mi fichero... Incluso con el usb quitado sigo viendo los
ficheros con ls en /media/usb /media/usb0 /media/usb1.
En el syslog al desconectar el usb:
Jul 2 16:49:53 localhost kernel: usb 1-3: USB disconnect, address 4
En el syslog al conectar el usb:
Jul 2 16:51:33 localhost kernel: ohci_hcd :00:0f.2: wakeup
Jul 2 16:51:33 localhost kernel: usb 1-3: new full speed USB device using
address 5
Mi /etc/usbmount.conf
FILESYSTEMS=ext2 ext3 vfat
MOUNTOPTIONS=sync,noexec,nodev,noatime
FS_MOUNTOPTIONS=-fstype=vfat,gid=floppy
VERBOSE=yes
Esto es rarito... ¿? ¿Alguna sugerencia más?
Elvis
-Mensaje original-
De: david sastre [mailto:[EMAIL PROTECTED]
Enviado el: martes, 01 de julio de 2008 18:31
Para: debian-user-spanish@lists.debian.org
Asunto: Re: Averiguar /dev
Hola a todos.
¿Por qué no pruebas a usar usbmount (empiezo a repetirme :)?
Lo tienes en marcha haciendo un
# aptitude install usmount
De mi /etc/usmount/usbmount.conf:
MOUNTPOINTS=/media/usb0 /media/usb1 /media/usb2 /media/usb3
/media/usb4 /media/usb5 /media/usb6 /media/usb7
(Por defecto te monta (automonta) los dispositivos USB en
/media/usb{0,1,2,3,...})
Por ahí lo tendrías fácil para localizarlos. Necesitas especificarle el tipo
de filesystems posibles, algo así como: (todas estas opciones también en
/etc/usmount/usbmount.conf)
FILESYSTEMS=ext2 ext3 vfat
Luego puedes ajustar otras opciones:
MOUNTOPTIONS=sync,noexec,nodev,noatime,users,umask=000
FS_MOUNTOPTIONS=-fstype=vfat,gid=floppy
VERBOSE=yes
Ésta última (verbosity) te permite ver si el automontado está funcionando.
Para ello haz un (como root)
# tail -f /var/log/syslog
Espero que te funcione.
--
Y el escribir a solas, sin finalidad, sin proyecto, porque sí, porque es
así, puede ofrecer el carácter de una acción trascendente, que sólo porque
se trata de una humanística acción no podemos llamarla sagrada. Mas algo
tiene de rito, de conjuro, y más aún, de ofrenda, de aceptación del
ineludible presente temporal, y de transitar en el tiempo, de salirse al
encuentro, como él hace, que no nos abandona.
(María Zambrano. El hombre y lo divino)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Averiguar /dev
Tengo la misma salida del ls con y sin el pen usb. He probado varios pens
por si a caso. La he comparado minuciosamente.
Elvis
-Mensaje original-
De: Jonay Domingo Ruiz [mailto:[EMAIL PROTECTED]
Enviado el: martes, 01 de julio de 2008 22:08
Para: debian-user-spanish@lists.debian.org
Asunto: Re: Averiguar /dev
Quizás sea rústico o incluso puede que en tu caso no funciones pero lo
comento por si acaso. En mi laptop al menos, con lenny, este es el ls /dev/
cuando no tengo conectado el pen (recortado un poco):
[EMAIL PROTECTED]:~$ ls /dev/
adsp dvdrwinputmem ram12 shm tty14 tty27 tty4
agpgart fd kmem mixer ram13 snapshot tty15 tty28 tty40
audiofull kmsg mixer1 ram14 snd tty16 tty29 tty41
audio1 hda log net ram15 sndstat tty17 tty3 tty42
bus hda1 loop nullram2stderrtty18 tty30 tty43
cdromhda2 loop0portram3stdin tty19 tty31 tty44
cdrw hda5 loop1ppp ram4stdouttty2 tty32 tty45
console hda6 loop2psaux ram5tty tty20 tty33 tty46
core hda7 loop3ptmxram6tty0 tty21 tty34 tty47
disk hda8 loop4pts ram7tty1 tty22 tty35 tty48
dri hda9 loop5ram0ram8tty10 tty23 tty36 tty49
dsp hdb loop6ram1ram9tty11 tty24 tty37 tty5
dsp1 hpet loop7ram10 random tty12 tty25 tty38 tty50
dvd initctl MAKEDEV ram11 rtc tty13 tty26 tty39 tty51
Y sin embargo con el pen drive conectado aparece esto(también recortado):
[EMAIL PROTECTED]:~$ ls /dev/
adsp fd kmsg netram2 sndstat tty18 tty31 tty45
agpgart full log null ram3 stderr tty19 tty32 tty46
audiohda loop port ram4 stdintty2 tty33 tty47
audio1 hda1 loop0pppram5 stdout tty20 tty34 tty48
bus hda2 loop1psaux ram6 tty tty21 tty35 tty49
cdromhda5 loop2ptmx ram7 tty0 tty22 tty36 tty5
cdrw hda6 loop3ptsram8 tty1 tty23 tty37 tty50
console hda7 loop4ram0 ram9 tty10tty24 tty38 tty51
core hda8 loop5ram1 randomtty11tty25 tty39 tty52
disk hda9 loop6ram10 rtc tty12tty26 tty4 tty53
dri hdb loop7ram11 sda tty13tty27 tty40 tty54
dsp hpet MAKEDEV ram12 sda1 tty14tty28 tty41 tty55
dsp1 initctl mem ram13 shm tty15tty29 tty42 tty56
dvd inputmixerram14 snapshot tty16tty3 tty43 tty57
dvdrwkmem mixer1 ram15 snd tty17tty30 tty44 tty58
A lo que voy es que en mi caso con el pen sin meter en ningún puerto no
aparece ni sda ni sda1(igual me pasa con un disco duro externo, cuando lo
conecto aparece sda, sda1, sda2, sda3, sda4, lógico porque tiene 4
particiones). Prueba a compara visualmente las salidas de ls /dev/ con tu
disco quitado y con él puesto.
Espero que te sirva, un saludo.
david sastre escribió:
Hola a todos.
¿Por qué no pruebas a usar usbmount (empiezo a repetirme :)?
Lo tienes en marcha haciendo un
# aptitude install usmount
De mi /etc/usmount/usbmount.conf:
MOUNTPOINTS=/media/usb0 /media/usb1 /media/usb2 /media/usb3
/media/usb4 /media/usb5 /media/usb6 /media/usb7
(Por defecto te monta (automonta) los dispositivos USB en
/media/usb{0,1,2,3,...})
Por ahí lo tendrías fácil para localizarlos. Necesitas especificarle
el tipo de filesystems posibles, algo así como: (todas estas opciones
también en
/etc/usmount/usbmount.conf)
FILESYSTEMS=ext2 ext3 vfat
Luego puedes ajustar otras opciones:
MOUNTOPTIONS=sync,noexec,nodev,noatime,users,umask=000
FS_MOUNTOPTIONS=-fstype=vfat,gid=floppy
VERBOSE=yes
Ésta última (verbosity) te permite ver si el automontado está funcionando.
Para ello haz un (como root)
# tail -f /var/log/syslog
Espero que te funcione.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Off topic - Programa en C para manejar puerto serial
Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico. ( http://www.soekris.com/net4521.htm). Dicha placa correrá el sistema operativo Linux Voyage. Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias -- p3dRø
Re: Off topic - Programa en C para manejar puerto serial
p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø Hoal pedro, me encantaria ayudarte pero desconozco. Mi pregunta es.. donde compraste el soekris, en que pais y demas. Yo soy de argentina y no los consigo por ningun lado. Gracias. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nun ca. [ Antes: Re: sobre nuevos errores]
- José Luis Triviño [EMAIL PROTECTED] wrote: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Por eso quisiera aprovechar este post para abrir un debate y conocer la opinión del resto de vosotros respecto a esta cuestión. ¿Está debian degenerando? o, como imagino, la cantidad de trabajo está desbordando a los mantenedores de paquetes de Debian. Con el riesgo de pérdida de calidad en la distribución o incluso su desaparición. Puede ser cierto lo que comentas pero mi tiempo trabajando con testing también me ha demostrado que es muy variable, en temporadas los paquetes dan su lucha y en otras son muy estable, en fin es la distribución de prueba. Creo que antes de formularnos preguntas que generarán debates extensos y ninguna solución deberíamos preguntarnos ¿Qué estamos haciendo por el proyecto Debian? Algún error corregido, alguna traducción?? En fin... los dejo con esta pregunta para ayudar a la reflexión madura de cómo funcionan los proyectos comunitarios. saludos cordiales Marcel PD: Perdón por el privado, se me escapó. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Off topic - Programa en C para manejar puerto serial
El día 2 de julio de 2008 10:12, Julián Esteban Perconti [EMAIL PROTECTED] escribió: p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø Hoal pedro, me encantaria ayudarte pero desconozco. Mi pregunta es.. donde compraste el soekris, en que pais y demas. Yo soy de argentina y no los consigo por ningun lado. Gracias. Hola la verdad yo no soy quien lo compra porque trabajo para un grupo de investigación. Te aconsejo que entres a la página http://www.soekris.com/net4521.htm y le escribas al mail del área de soporte o de márketing. Suerte! Por favor alguien tiene sugerencias sobre el *programa en C* que permita manejar el *puerto serial DB9* para la configuración que les expliqué anteriormente ? -- p3dRø
Re: Averiguar /dev
2008/7/1 Elvis Aaron Presley [EMAIL PROTECTED]: Hola listeros, tengo un debian sarge sin entorno gráfico al que al pinchar un disco duro usb no soy capaz de acceder a dicho disco duro. Este usb está formateado en fat32. Conozco perfectamente el comando mount que tengo que hacer para montarlo... El problema es que no se en que /dev está No se si es /dev/sda1 o /dev/usb/ez0 o donde mirar esto... ¿algún comandito mágico que me pueda alumbrar? Gracias. Elvis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] 1.-Cuando lo conectas no te dice nada en dmesg? 2.-Si haces un cat /proc/partitions antes de conectarlo y despues de conectarlo? 3.-blkid te soltara un monto de informacion siempre como root claro xD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(sin asunto)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Off topic - Programa en C para manejar puerto serial
p3dRø escribió: El día 2 de julio de 2008 10:12, Julián Esteban Perconti [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø Hoal pedro, me encantaria ayudarte pero desconozco. Mi pregunta es.. donde compraste el soekris, en que pais y demas. Yo soy de argentina y no los consigo por ningun lado. Gracias. Hola la verdad yo no soy quien lo compra porque trabajo para un grupo de investigación. Te aconsejo que entres a la página http://www.soekris.com/net4521.htm y le escribas al mail del área de soporte o de márketing. Suerte! Por favor alguien tiene sugerencias sobre el *programa en C* que permita manejar el *puerto serial DB9* para la configuración que les expliqué anteriormente ? -- p3dRø Hola. Se me ocurre algo, basado en la información que das. No tengo idea a que te refieres con PIR (de momento asumo que son alguna clase de sensor de movimiento que cuando se activa manda una señal de 5V), pero si vas a fabricar una pieza de hardware que los controle y que al recibir alguna señal de ellos vas a mandar información a través del puerto serial, creo que no estas enfocando las cosas como son. De momento y asumiendo que lo anterior es cierto. necesitarías usar un hardware intermedio entre el PIR y el puerto serial. Ya sea un microcontrolador (PIC? , Atmel?) o un MAX232 que te reciba los datos paralelos de los PIR y te los convierta a serie, de aquí para adelante la programación en C es sencilla porque lo único que tienes que hacer es utilizar las rutinas de lectura del puerto serial de las que hay miles de ejemplos en la internet, pero te repito, estoy tratando de entender lo que quieres hacer con la poca información que das. Visto de esta manera tu problema esta en generar un protocolo de tal forma que el micro o lo que uses te mande un dato en caso de actividad o no de cada uno de los sensores y leas ese dato con las rutinas estándar de C. En cuanto a tu idea de censar alguno de los pines del puerto, pues, yo hacia cosas como esas en mis antiguos tiempos de MS-DOS 5.0 con interrupciones del sistema, pero creo que en linux una vez las trate de usar y creo que el sistema operativo no te deja, además, si usaras un puerto paralelo la idea de censar un pin seria viable pero dado que vas a usar un puerto serial esto no es muy útil que digamos ya que hay en juego muchos flancos y cosas por el estilo que no te dejarían hacer las cosas como quieres hacerlas. Esto solo por comentar. Comenta y te insto a que este tipo de preguntas las hagas por otro tipo de listas mas especializadas en cosas de hardware o electrónicas creo que te seria mucho mas útiles para este caso Suerte -- Por favor, NO utilice formatos de archivo propietarios para el intercambio de documentos, como DOC y XLS, sino HTML, PDF, TXT, CSV o cualquier otro que no obligue a utilizar un programa de un fabricante concreto. Internet Explorer y Outlook son muy peligrosos por sus continuos problemas de seguridad. Utilice alternativas libres: http://www.mozillaes.org/ usuario linux registrado #387231 http://counter.li.org Por favor evite enviar adjuntos de powerpoint y word vea http://www.gnu.org/philosophy/no-word-attachments.es.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analizar log de dansguardian ON LINE y disparar evento
adriancito escribió: Hola Lista. Es posible analizar ON LINE los logs de dansguardian y ante algún evento (por ejemplo la visita de alguna página indevida) disparar un script? Este tipo de controles puede generar recargas en el servidor? Muchas Gracias. Saludos Adrian, Te comento que yo he logrado analizar los logs de D.G online desde el webmin con la aplicción Sarg[1] y me funciona muy bien, solo que debes configurar en el dansguardian que genere los logs con el formato del squid, ya que el Sarg funciona con el formato del squid. Por lo otro que preguntas si no se como hacerlo, pero no te lo recomiendo ya que se generarían muchos procesos de páginas denegadas a no ser que sean uno que otro usuario. Saludos... [1] http://sarg.sourceforge.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[SOLUCIONADO] Re: Squid Carga página Desactua lizada
Alonso Caballero Quezada / ReYDeS escribió: Saludos: On Tue, Jul 1, 2008 at 3:18 PM, Carlos Eduardo Velásquez Chaves [EMAIL PROTECTED] wrote: ciracusa escribió: Carlos Eduardo Velásquez Chaves wrote: Saludos a todos, Estoy usando un Squid + Dansguardian + iptables para el proxy de mi red. El asunto es que me carga ciertas páginas de la primera vez que se había cargado la página, por ejemplo www.nacion.com me carga la de el día 17 de Junio. Incluye en una archivo todas aquellas URL que no deseas que sean almacenadas en Caché del Proxy, y crea el ACL respectivo en el archivo de la configuración de SQUID. Atte: Muchas gracias por las sugerencias, agrego la solución basada en el comentario del compañero Alonso: 1. Hacer un archivo en /etc/squid vim sitios_no_cache Luego agregas las direcciones de la siguiente manera en el archivo: .nacion.con .sitioxy.com .loquesea.com Recuerda poner el punto antes del sitio si no no funciona (me corrigen si me equivoco a mi no me funionaba) 2. Configurar el squid.con agregando las siguientes líneas: ##SITIOS NO CACHEADOS acl sitios_no_cache dstdomain /etc/squid/sitios_no_cache no_cache deny sitios_no_cache always_direct allow sitios_no_cache Saludos espero les sirva. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Off topic - Programa en C para manejar puerto serial
El día 2 de julio de 2008 10:36, Jhosue Rui [EMAIL PROTECTED] escribió: p3dRø escribió: El día 2 de julio de 2008 10:12, Julián Esteban Perconti [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø Hoal pedro, me encantaria ayudarte pero desconozco. Mi pregunta es.. donde compraste el soekris, en que pais y demas. Yo soy de argentina y no los consigo por ningun lado. Gracias. Hola la verdad yo no soy quien lo compra porque trabajo para un grupo de investigación. Te aconsejo que entres a la página http://www.soekris.com/net4521.htm y le escribas al mail del área de soporte o de márketing. Suerte! Por favor alguien tiene sugerencias sobre el *programa en C* que permita manejar el *puerto serial DB9* para la configuración que les expliqué anteriormente ? -- p3dRø Hola. Se me ocurre algo, basado en la información que das. No tengo idea a que te refieres con PIR (de momento asumo que son alguna clase de sensor de movimiento que cuando se activa manda una señal de 5V), pero si vas a fabricar una pieza de hardware que los controle y que al recibir alguna señal de ellos vas a mandar información a través del puerto serial, creo que no estas enfocando las cosas como son. De momento y asumiendo que lo anterior es cierto. necesitarías usar un hardware intermedio entre el PIR y el puerto serial. Ya sea un microcontrolador (PIC? , Atmel?) o un MAX232 que te reciba los datos paralelos de los PIR y te los convierta a serie, de aquí para adelante la programación en C es sencilla porque lo único que tienes que hacer es utilizar las rutinas de lectura del puerto serial de las que hay miles de ejemplos en la internet, pero te repito, estoy tratando de entender lo que quieres hacer con la poca información que das. Visto de esta manera tu problema esta en generar un protocolo de tal forma que el micro o lo que uses te mande un dato en caso de actividad o no de cada uno de los sensores y leas ese dato con las rutinas estándar de C. En cuanto a tu idea de censar alguno de los pines del puerto, pues, yo hacia cosas como esas en mis antiguos tiempos de MS-DOS 5.0 con interrupciones del sistema, pero creo que en linux una vez las trate de usar y creo que el sistema operativo no te deja, además, si usaras un puerto paralelo la idea de censar un pin seria viable pero dado que vas a usar un puerto serial esto no es muy útil que digamos ya que hay en juego muchos flancos y cosas por el estilo que no te dejarían hacer las cosas como quieres hacerlas. Esto solo por comentar. Comenta y te insto a que este tipo de preguntas las hagas por otro tipo de listas mas especializadas en cosas de hardware o electrónicas creo que te seria mucho mas útiles para este caso Suerte -- Exacto, voy a utilizar un Max232 que haga de adaptador entre los 2 PIR y el puerto serial. Ahora dicho programa en C solo necesito de que monitoree eventos en el pin de recepción. Qué rutinas de lectura del puerto serial debo utilizar? por otro lado también debo utilizar interrupciones? Me puedo ayudar del minicom (software que manejar el puerto serial sobre Linux) para este propósito ? de qué forma? -- p3dRø
RE: Off topic - Programa en C para manejar puerto serial
p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø -- p3dRø -- Que tal, Hace tiempo hice un programa en C++ (bajo Windows) el cual trabajaba con una función propia del lenguaje llamada outport y otra llamada outportb (o algo parecido, eso ya fue hace mucho tiempo) estas hacían la comunicación con el puerto LPT1 y podías especificar el No. de PIN del puerto y el puerto (en mi caso era LPT1) y con lo cual podía conseguir, por ejemplo, prender o apagar una secuencia de LEDs simplemente diciéndole a la función qué No. de PIN encender/apagar. Revisa la ayuda del C++ allí hay unos buenos ejemplos con los cuales yo me base en ese tiempo. Suerte, espero te sea de utilidad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Load balancing con 2 conexiones pppoe
Buen dia lista pues aki con una duda que espero alguien me pueda resolver... Resulta que tengo 2 adsl con telmex de 2048 kbps de bajada por 256 de subida cada una... Y quiero hacer un load balancing.. mi problema o duda ke tengo es ke resulta que me conecto a esas dos adsl por pppoe. Y como uno des los enlaces tiene ip dinamica y el otro ip fija me gustaria saber si es posible hacer el load balancing con dos conexiones pppoe.. Ya que todos los manuales que he visto y leido las conexiones las pasn por routers y les dan una ip clase c.. Alguien a tenido este problema? Y si es asi como lo puedo resolver? De antemano gracias a todos por su atencion.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ A ntes: Re: sobre nuevos errores]
José Luis Triviño escribió: Abraham Pérez wrote: El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Creo que no termino de entender este mail... si usas testing y/o sid ya sabes lo que estás asumiendo. Si usas stable ya sabes que no vas a tener ningún tipo de problema a costa de no tener las últimas versiones del software que pudiera ir saliendo. Decir que Debian pueda desaperecer por estar usando testing y tener dependencias rotas me parece, sinceramente, ridículo. Pido disculpas de antemano si alguien cree que el tono empleado no es el adecuado, pero es que estoy ya cansado de escuchar a la gente diciendo que Debian terminará desapareciendo por Ubuntu y tonterías de similar calibre. Esta bien! Lo preguntaré de otra forma para que hasta tú puedas entenderlo: ¿Crees que debian testing es más inestable en la actualidad que hace unos años? Yo creo que si. Y creo que esto puede estar afectando a la calidad de Debian. No creo que sea ridículo plantearselo cuando todos sabemos que la vesrión estable de debian en muchos casos no ofrece la versión del programa que necesitamos. Yo vengo desde hace bastante tiempo utilizando la versión testing y nunca tuve ningún problema. Instalaba todo tan bien como en la estable y tenía las versiones de programas que me interesaban. De unos meses a la actualidad me encuentro que esos programas no están en la estable y no instalan correctamente en la inestable. Luego creo que puede estar bajando la calidad de la distribución. Y eso es lo que comento aquí. No creo que sea un comentario ridículo. Si en otras distribuciones te encuentras la versión que necesitas del programa integrada en la distribución de forma más estable eso podría perjudicar a Debian. Y no digo nada necesariamente de Ubuntu. Que parece que te ha tocado la vena sensible. Saludos, P.D. En posteriores respuestas a una lista procura hacer el ridículo evitando palabras como ridículo o tonterías. El intercambio de opiniones razonado nunca es ridículo ni tonto. Sino constructivo. Tenga quien tenga la razón y se llegue a la conclusión que se llegue. Desgraciadamente creo que hay un poco de verdad en este tema, actualmente están saliendo los paquetes mucho mas rápidamente que la vercion anterior de debian, estamos hablando de nivel estable solamente. Esto puede ser causado por presiones y por que muchos prefieren las cosas mas fáciles y es un es-tiradero por todos lados, ademas abuntu a presionado con su tipo de desarrollo, pero eso desde mi punto de vista esta en un error, sin embargo esta afectando a debian puesto que las personas que no comprenden debian y me refiero a su filosofía del sistema, están gritando por todas partes. Por otra parte el error en el SSL continuara causando efectos negativos por un tiempo mas, un error lo comete cualquier persona, pero también debemos comprender que hay muchas personas que atacan a debian por el simple hecho que no le pueden instalar y configurar, pero nunca quieren leer un manual y debian creo que de alguna forma esta haciendo caso a este tipo de personas. Desde mi punto de vista creo que debian debe tener como prioridad la seguridad, sin importar es mas complicada su instalación y configuración, puesto que esa es la bandera que a llevado de siempre, por que cambiarle hoy?. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limitar a un usuario a que so lo pueda ejecutar telnet en su sesión?
de nada, no hay de que, mira ... antes conocía algunas fake shells por así decirlo que lo que hacían era imitar el comportamiento de bash y dejaban todo logueado en un archivo para mantener controlado al usuario. Abría que investigar si hay shells configurables por ahí que te permitieran hacer algo parecido además de añadir y quitar características a la shell. Lo que pides puede resultar algo intrusivo, aunque una buena alternativa sería instalar un keylogger siempre te arriesgas a que el usuario se de cuenta y se muestre reacio a usar tu sistema, por eso te envío este comando de cosecha propia que seguro que te sirve y te va de maravilla, simplemente creado con comandos propios de cualquier unix sin instalar nada externo: *watch --interval=0,1 setterm -dump 1* ,- el número 1 lo cambias por la consola que quieras loguear, eso te crea un archivo screen.dump en el directorio donde lo lanzes que en otra terminal puedes loguear en tiempo real con el comando: tail -F screen.dump y listo, ya tienes el usuario monitorizado a full ;) Un saludo y espero que te sirva -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternativa a phpBB
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 El 02/07/08 16:46, Jose Ruiz García escribió: Me gustaría conocer vuestras opiniones acerca de algún software para crear un foro alternativo a phpBB. Descarto este de primeras debido a su largo historial de vulnerabilidades que me llevan a no darme ninguna confianza. Te puede servir el Simple Machines Forum. Es una alternativa fiable (al menos lo tengo aquí, bajo un directorio de pruebas). - -- Slds de Santiago José López Borrazás Conocimientos avanzados en seguridad informática. Conocimientos avanzados en redes. El 12 de julio, esta máquina, ya va a estar Down... -BEGIN PGP SIGNATURE- iQIVAwUBSGvIhLuF9/q6J55WAQrCkg/9HhgRyBSm/2GognzfHjqOd5xxC5pEz4ew MKMXE6G13W0nERI/muOX4+95any0VwcAShUnPBEGVtxdkPX1ZcQrZSkDzPoWoUcV UBhAaCFtpOP6N15zHfVppNS7RbA1EOzvrzMi7lSeGo68dauEYGvecDX6iwuq3h8f VJUW/E6E66ApCWWrHj1RbphNjXeLidcgv8+U5ihxf2+geVKZpiOWWnfm/sLjPBMR +cbZLNmWOwob+VcX8xwyHEhK1DFWJdLA+KOMUxWJR/LIpBg2SruH/vQvkFMmck62 Z+bhkjiJWIQRBasjak3M3vvhnOyFFI6bl2E+StDVbkQ/LHEwbKsKIjaIZHHVDxyR 72TW5iukltWIcRzLYBv9LpTWagLVtkTrBl/O4erkthoxRPNmwUPrbKL/SYzzmtJJ hCUKzLXPFwWFlaEbgieBQhwdBYkNN9Og06PkgOEvgs6RN1+UpLrLq3EeaTOuQPtb QbxC97RSTcMKLClL32XRk8XYVDDNohsy2PTAq1xWevuKiGvy8smCNXUTU9w+P1mZ ihPk4Bc5RX0bJhQzbmcvqBfZmSieL3faTuooslZsYF4lccuCfZSkkirawOJzQGZR D2C92neID6xxEgmr3jw5cSX+hctIlowFTqkDj7TBsnGKB1dn4Ds8s0boeuG3aI/i maV5upoZkxk= =99/A -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Load balancing con 2 conexiones pppoe
Hola, pues no lo he probado nunca pero en principio no debería tener problemas puesto que (al menos en linux) cuando creas un bouncing entre las dos interfaces te genera una interfaz virtual que es la suma de las dos por así decirlo. Como te digo no lo he probado con ip dinámica, pero la mejor forma de saberlo es probándolo asi que si lo pruebas nos comentas. un saludo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Regla de iptables
Emilio wrote: El mié, 02-07-2008 a las 10:25 -0300, ciracusa escribió: Emilio wrote: Hola lista, Tengo un problemilla con iptables. A ver si me podéis echar una mano, pero no al cuello ;) Tengo un pc que hace de firewall (iptables) funcionando perfectamente para mis necesidades claro. Tiene dos tarjetas de red, una que esta enchufada al router wireless de internet (eth0) y la otra que va a un switch que este a su vez enchufa a otros pc's (eth1). Dentro de la red local (eth1) hay una impresora en red que me gustaría compartir con las dos interfaces de tal forma que la gente que se conecta al router wireless, puedan acceder perfectamente a esa impresora que esta dentro de la red local. He estado probando varias reglas con forward, forward con nat... pero ninguna me ha funcionado. Sabéis si esto que quiero hacer es posible hacerlo? Me podéis arrojar algo de luz? Un saludo y muchas gracias por vuestra ayuda. Emilio, porque no empiezas por postear tu script de iptables? Por otro lado, suponiendo que la IP de la Impresora de Red sea 192.168.0.1, podrías probar con algo como: iptables -A INPUT -p tcp -i eth0 -d 192.168.0.1 -j ACCEPT Saludos. Hola, Muchas gracias por contestar con tanta rapidez. Cuando llegue a casa pruebo lo que me comentas y, os posteo el script de iptables. Para Miguel Da Silva: La impresora no esta enchufada a ningún equipo, es decir, esta tiene su propia tarjeta de red con lo que es como si fuera un equipo mas de la red. Muchas gracias de nuevo. Un saludo. Emilio Bien... pero como ella es compartida?! Este dato es importante para saber como armar las reglas. Si los usuarios imprimen directamente a la impresora, entonces las reglas deberán contener la IP de la impresora. Sin embargo, si hay algún sistema controladola (mejor dicho, controlando la fila de impresiones), entonces la IP debería ser de este sistema. Saludos. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Load balancing con 2 conexiones pppoe
On Wed, Jul 2, 2008 at 3:29 PM, nx [EMAIL PROTECTED] wrote: Hola, pues no lo he probado nunca pero en principio no debería tener problemas puesto que (al menos en linux) cuando creas un bouncing entre las dos interfaces te genera una interfaz virtual que es la suma de las dos por así decirlo. Como te digo no lo he probado con ip dinámica, pero la mejor forma de saberlo es probándolo asi que si lo pruebas nos comentas. Error..!!! Bouncing no sirve para lo que el necesita...ya que el concepto de bouncing es cuando se cae una de las interfaces entonces hace el cambio del enrutamiento por la otra... Lo que el necesita es usar iproute2 http://lartc.org/howto/lartc.rpdb.multiple-links.html Saludos -- La Voluntad es el unico motor de nuestros logros Mstaaravin / http://www.mstaaravin.com.ar/
Re: Limitar a un usuario a que solo pueda ejecutar telnet en su sesión?
El día 30 de junio de 2008 17:09, Manuel Soto [EMAIL PROTECTED] escribió: 2008/6/29 adriancito [EMAIL PROTECTED]: Buenas lista. Como podría hacer para que un determinado usuario, luego de conectarse vía SSH a un server Linux solo tenga disponible el comando telnet? Es mas, quisiera que solo pueda hacer telnet a una determinada ip de la red exclusivamente. Muchas Gracias. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Yo diría que el .profile llame a un shell que presente un menu y solo le permita hacer el telnet o salir. Tienes que atrapar los signals para que no se salga o suspenda Manuel Soto Sólo para aclarar, cuando me refería a un shell es un shellscript ó en el caso más restrictivo en el mismo .profile invocas al telnet con la dirección que indicas quieres que se conecte, algo como ... trap false SIGABRT SIGSTOP telnet host #fin del .profile
Re: Off topic - Programa en C para manejar puerto serial
El día 2 de julio de 2008 11:58, frank [EMAIL PROTECTED] escribió: p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø -- p3dRø -- Que tal, Hace tiempo hice un programa en C++ (bajo Windows) el cual trabajaba con una función propia del lenguaje llamada outport y otra llamada outportb (o algo parecido, eso ya fue hace mucho tiempo) estas hacían la comunicación con el puerto LPT1 y podías especificar el No. de PIN del puerto y el puerto (en mi caso era LPT1) y con lo cual podía conseguir, por ejemplo, prender o apagar una secuencia de LEDs simplemente diciéndole a la función qué No. de PIN encender/apagar. Revisa la ayuda del C++ allí hay unos buenos ejemplos con los cuales yo me base en ese tiempo. Suerte, espero te sea de utilidad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Lo que yo quiero que al momento de detectar un evento en el puerto serial el programa en C active un script que por ejemplo cree una carpeta nueva en el directorio home. Así, de ese modo, solo necesito de que el puerto serial esté en escucha y NO en trasmisión. Por ahi he encontrado código en C, lo cual estoy estudiando que es el link: http://www.ontrak.net/linux.htm Si saben más del tema y me pudiesen ayudar estaré muy agradecido. Por ahora estoy analizando la función que se encuentra en el archivo adrserial.c *ReadAdrPort(sResult,254)* Saludos, -- p3dRø
RE: Off topic - Programa en C para manejar puerto serial
Que tal, No sabría indicarte si existen diferencias entre la programación entre un S.O. y otro (hablando de C++). Lo que te puedo decir es que mi proyecto lo hice en el Borland C++ de hace como 5 años sobre Windows ME. No creo que existan diferencias pues al parecer según tu link la sintaxis es igual. Lo que tienes que ver es como llamar al puerto serial, y dentro de éste cómo trabajar con cada uno de los pines de dicho puerto, hecho esto la sintaxis es lo de menos ya que incluso lo podrías hacer en visual basic si quisieras o en Mono. http://www.conclase.net/c/Borland/macro.php?mac=outportb http://www.conclase.net/c/Borland/funcion.php?fun=outport http://www.geocities.com/gear996/sub/parallel.html De: p3dRø [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 02 de julio de 2008 11:34 Para: debian-user-spanish@lists.debian.org Asunto: Re: Off topic - Programa en C para manejar puerto serial El día 2 de julio de 2008 10:36, Jhosue Rui [EMAIL PROTECTED] escribió: p3dRø escribió: El día 2 de julio de 2008 10:12, Julián Esteban Perconti [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: p3dRø escribió: Hola amigos listeros, Quiero hacer una conexión de 2 PIR (detectores de movimiento) se comuniquen con el puerto serial DB9 de una placa soekris enrutador inalámbrico (http://www.soekris.com/net4521.htm). Para eso voy a hacer un hardware que es un adaptador para conectar ambos PIR al puerto serial. Por otro lado también necesito hacer un programa para la placa soekris que monitorice su puerto serial constantemente y que cuando reciba un voltaje de 5 V entonces active un script. No tengo noción de dónde empezar o si hay ejemplos parecidos en Internet o ustedes ya han hecho algo similar. Por favor necesito ayuda por esa parte. Yo creo que tengo que monitorizar únicamente el pin de recepción. Es correcto? Cualquier sugerencia o info me será de gran ayuda. Gracias. -- p3dRø -- p3dRø -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Regla de iptables
El 02/07/2008, a las 20:14, Miguel Da Silva - Centro de Matemática escribió: Emilio wrote: El mié, 02-07-2008 a las 10:25 -0300, ciracusa escribió: Emilio wrote: Hola lista, Tengo un problemilla con iptables. A ver si me podéis echar una mano, pero no al cuello ;) Tengo un pc que hace de firewall (iptables) funcionando perfectamente para mis necesidades claro. Tiene dos tarjetas de red, una que esta enchufada al router wireless de internet (eth0) y la otra que va a un switch que este a su vez enchufa a otros pc's (eth1). Dentro de la red local (eth1) hay una impresora en red que me gustaría compartir con las dos interfaces de tal forma que la gente que se conecta al router wireless, puedan acceder perfectamente a esa impresora que esta dentro de la red local. He estado probando varias reglas con forward, forward con nat... pero ninguna me ha funcionado. Sabéis si esto que quiero hacer es posible hacerlo? Me podéis arrojar algo de luz? Un saludo y muchas gracias por vuestra ayuda. Emilio, porque no empiezas por postear tu script de iptables? Por otro lado, suponiendo que la IP de la Impresora de Red sea 192.168.0.1, podrías probar con algo como: iptables -A INPUT -p tcp -i eth0 -d 192.168.0.1 -j ACCEPT Saludos. Hola, Muchas gracias por contestar con tanta rapidez. Cuando llegue a casa pruebo lo que me comentas y, os posteo el script de iptables. Para Miguel Da Silva: La impresora no esta enchufada a ningún equipo, es decir, esta tiene su propia tarjeta de red con lo que es como si fuera un equipo mas de la red. Muchas gracias de nuevo. Un saludo. Emilio Bien... pero como ella es compartida?! Este dato es importante para saber como armar las reglas. Si los usuarios imprimen directamente a la impresora, entonces las reglas deberán contener la IP de la impresora. Sin embargo, si hay algún sistema controladola (mejor dicho, controlando la fila de impresiones), entonces la IP debería ser de este sistema. Saludos. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy Los usuarios imprimen directamente a la impresora. Muchas gracias por contestar. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Off topic - Programa en C para manejar puerto serial
Hola: Aquí tienes varios ejemplos de cómo hacerlo. http://tuxgraphics.org/electronics/ S2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: freeradius ssl recompilar
El lun, 30-06-2008 a las 17:34 +0200, Antonio Trujillo Carmona escribió: Necesito conectar el freeradius con un AD, para eso se necesitan peap que depende de openssl, pero el paquete de debian esta compilado sin ssl. Puedo instalar del tgz original de freeradius, pero prefiero no dejar sucio el sistema, por lo que he pensado en dos opciones. A) recompilar con apt-build el paquete añadiendo las librerias ssl. B) como el paquete trae un directorio /debian generar un paquete con dpkg-buldpackage. ¿Cual opción es mejor?, ¿Como aprender a hacerlo? ¿Hay otra forma? Final mente opte por apt-build, teniendo instaladas las libss-dev parece que todo funciona. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
El día 2 de julio de 2008 14:06, Salvador Garcia Z. [EMAIL PROTECTED] escribió: José Luis Triviño escribió: Abraham Pérez wrote: El día 2 de julio de 2008 9:25, José Luis Triviño [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escribió: Hola amigos, solo escribo para comentar que luego de usar stable y etch me he pasado desde hace unos meses a testing y no he tenido ningun problema atribuible a la distribucion, un par de problemas en las actualizaciones fueron por mi torpeza al no tener marcados unos repositoriorios de debian-multimedia y luego otro que fué por una caida de la conexion mientras actualizaba pero que solucioné con un dpkg -f. Uso ahora testing en mi notebook del inspiron 1300, en mi pc de escritorio un athlon 900 pero en mi servidor uso estable. Como dato menciono que en el notebook probe ubuntu un tiempo y ahi si que tenia problemas seguido, use ubuntu de la 5,10 pero el paso a la 6.04 fue un desastre reinstalacion desde cero mediante, y luego al pasar a la 6.10 igualmente traumatico. ¿porque tendemos a generalizar nuestras experiencias y suponer que a todos les sucede lo mismo? conozco gente que jamas han podido instalar debian, aunque si otras distros, otros como yo no hemos tenido buenas experiencas con ubuntu, pero no por ello puedo decir que es una mala distro. Un saludo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- usuario linux #274354 normas de la lista: http://wiki.debian.org/NormasLista -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing má s testing que nunca. [ Antes: Re: sobre nuevos errores]
On Wed, Jul 02, 2008 at 09:25:03AM +0200, José Luis Triviño wrote: Hola, La verdad es que estos problemas no sólo los tienes tú. Últimamente he observado que las versiones testing y unstable de Debian tienen más fallos de lo habitual. Antes podía usar testing casi como stable. Prácticamente casi todo iba bien. Por eso siempre he creído que Debian era una de las distribuciones más estables y con menos errores. Pero de unos meses acá encuentro programas con bugs importantes o paquetes dependencias incumplidas que no dejan actualizar el sistema. Respecto de ésto último lo que pasa con más frecuencia es que se utilizan plataformas de desarrollo que no son i386. El paquete se acepta como tal en la plataforma en la que se ha preparado y luego pasa a los auto-builders para las demás. Si es un paquete sencillo no hay problemas y en las plataformas habituales se hace enseguida. Si es un monstruo como Openoffice (que se envía en powerpc), el autobuilder de i386 necesita tiempo (creo que más de una hora en una máquina potente) para compilarlo. Si en ese tiempo ocurre el ciclo de paso de 'incoming' a 'sid' el paquete de i386 tiene que esperar al día siguiente con lo que hay una falta de sincronízación durante un día. También ocurre cuando hay una transición gorda (y ha habido varias recientemente) que quedan paquetes que aún no se han actualizado y que se convierten en no instalables hasta que se arreglan. Eso no debiera ocurrir en testing en las plataformas principales. Son los inconvenientes de utilizar 'unstable', aka sid. Cuando eso ocurre suele ser preferible dejar los paquetes afectados en espera e ir probando a ver cuando entran, salvo que se conozca bien el sistema. En cualquier caso hay casos y casos, pero si se utiliza 'sid' no hay que olvidar que se están utilizando paquetes en estado 'unstable' y que a pesar de las precauciones que haya podido tomar el responsable del paquete, no hay nada como la vida real para que salgan todos los bichos escondidos. En general, si se utiliza 'unstable', no está en absoluto de más leer regularmente 'debian-devel' para estar al corriente de transiciones gordas o problemas esperados. Y, aunque parezca pesado, es bueno ponerse al día con la lectura de 'debian-devel' antes de actualizar 'unstable'. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian testing más testing que nunca. [ Antes: Re: sobre nuevos errores]
On Wed, 2008-07-02 at 10:55 -0400, Jonatan Alballay wrote: Pues me sumo a lo que dice Jose, esta mas testing que nunca, habra que esperar hasta fin de año para que se regularize la situacion... Este mensaje dice todo por mi en relacion a este hilo: Cual es la condicion regular de Testing? Pues es: Pruebas, o sea que esta en manos de usuarios que realizamos pruebas, antes de ser estable! Yo diria, que Debian, esta constituido por, los desarrolladores (quienes hacen el trabajo duro y a quienes van mis agradecimientos), los usuarios ( que podrian estar divididos en usuarios de estable, pruebas, inestable y experimental; yo uso estable en la oficina y pruebas en mi portatil, sin problemas en estable dede hace 6 o 7 anos y divirtiendome y aprendiendo con pruebas, y con la esperanza de pasarme a inestable o experimental. Para contribuir en algo); luego los equipos de traduccion, que tambien hacen buen trabajo, gracias. (yo tengo que usar 3 idiomas distintos.) Como facilmente, podemos ver, Debian no es solamente una distribucion (algo que hace Mister-X para el vulgo); es producto de todos y es por eso que has recibido mensajes que muestran admiracion, dado que hablar de Debian, es hablar de ti mismo! Asumiendo que usas Debian! Gracias. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
