RE: [OT] Re: pin off bluetooth
Windows Live Hotmail To set plain text for a single message - (while composing your post) Toolbar = Rich Text = Plain Text = OK. A ver si mejora. Gracias Ramses, voy a probar todo lo que me dices y comento. Ya me empezaba a obsesionar con esto. De todas maneras tambien voy a repasar el bash-history porque anoche hice una prueba mas en otro laptop antiguo con debian 686 con bluez, ussp, obex y bluetooth-dongle en el usb y efectivamente pide pin como deberia ser normal. Es alguna modificación que hay en mi pc de uso diario, el cual no pide emparejamiento a ningun móvil.
Archivo no encontrado u oculto en memoria usb
Buenos días. Hace unas horas copié un archivo .wav en una memoria usb desde una pc con win7. La pc no es mía y no tengo acceso pleno a ella. Cuando lo monto en mi debian 7 con lxde, el archivo pareciera no existir. No puedo localizarlo. Probé con ctrlH pero nada. Volví a enchufar la memoria en esa máquina con win7 y el archivo está ahí. Volví a copiarlo, pero me ocurre lo mismo cuando vuelvo a montarlo en debian, es decir: el archivo no se ve de ningún modo. Qué podrá estar ocurriendo? Gracias. -- Martín Ayos === http://www.martinayos.nsmweb.com.ar http://www.ratakruel.nsmweb.com.ar === Linux User # 481475 ===
Re: Archivo no encontrado u oculto en memoria usb
El 16 de diciembre de 2014, 9:52, martin ayos martin.a...@gmail.com escribió: Buenos días. Hace unas horas copié un archivo .wav en una memoria usb desde una pc con win7. La pc no es mía y no tengo acceso pleno a ella. Cuando lo monto en mi debian 7 con lxde, el archivo pareciera no existir. No puedo localizarlo. Probé con ctrlH pero nada. Volví a enchufar la memoria en esa máquina con win7 y el archivo está ahí. Volví a copiarlo, pero me ocurre lo mismo cuando vuelvo a montarlo en debian, es decir: el archivo no se ve de ningún modo. Qué podrá estar ocurriendo? Gracias. -- Martín Ayos === http://www.martinayos.nsmweb.com.ar http://www.ratakruel.nsmweb.com.ar === Linux User # 481475 === Me respondo a mí mismo y agrego un dato que me parece sumamente raro: El archivo en cuestión sí aparece en Nautilus. Pero PCMan no lo muestra. No entiendo la razón. Gracias nuevamente. -- Martín Ayos === http://www.martinayos.nsmweb.com.ar http://www.ratakruel.nsmweb.com.ar === Linux User # 481475 ===
Re: Archivo no encontrado u oculto en memoria usb
Me respondo a mí mismo y agrego un dato que me parece sumamente raro: El archivo en cuestión sí aparece en Nautilus. Pero PCMan no lo muestra. No entiendo la razón. Gracias nuevamente. -- Martín Ayos === http://www.martinayos.nsmweb.com.ar http://www.ratakruel.nsmweb.com.ar === Linux User # 481475 === No si es el caso, pero a mi me sucedió varias veces que usando pcmanfm si no precionaba f5 no actualizaba bien los cambios en los archivos. Me sucedio en varias ocasiones. Puede que sea por eso. -- Pablo
Re: Archivo no encontrado u oculto en memoria usb
El 16 de diciembre de 2014, 10:20, Pablo pablocar...@gmail.com escribió: Me respondo a mí mismo y agrego un dato que me parece sumamente raro: El archivo en cuestión sí aparece en Nautilus. Pero PCMan no lo muestra. No entiendo la razón. Gracias nuevamente. -- Martín Ayos === http://www.martinayos.nsmweb.com.ar http://www.ratakruel.nsmweb.com.ar === Linux User # 481475 === No si es el caso, pero a mi me sucedió varias veces que usando pcmanfm si no precionaba f5 no actualizaba bien los cambios en los archivos. Me sucedio en varias ocasiones. Puede que sea por eso. -- Pablo Gracias por la respuesta. La verdad es que no comprendo cuál será el motivo. -- Martín Ayos === http://www.martinayos.nsmweb.com.ar http://www.ratakruel.nsmweb.com.ar === Linux User # 481475 ===
Sobre dns secundario
Hola lista. Llevo dias ya con una duda, tengo un servidor secundario dns (bind9) instalado en debian 7 y el servidor primario es un win2 server 2008, mi duda es la siguiente. Desde el servidor secundario se pueden modificar la zona ? --- Consulte la Enciclopedia Colaborativa Cubana http://www.ecured.cu/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54903bc6.9060...@ucf.edu.cu
Re: [OT] Re: pin off bluetooth
El Tue, 16 Dec 2014 09:36:07 +, franiortiz hotmail escribió: Windows Live Hotmail To set plain text for a single message - (while composing your post) Toolbar = Rich Text = Plain Text = OK. ¿En serio? X-) A ver si mejora. (...) Pues va a ser que no. No entiendo qué complicación puede haber en seleccionar un formato de texto plano para los mensajes... Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.14.41...@gmail.com
Re: Fwd: fglrx-driver
El Mon, 15 Dec 2014 19:18:03 +0100, Javier Silva escribió: (ese html...) El 14/12/2014 17:20, Camaleón noela...@gmail.com escribió: Hola a todos, También tengo el mismo problema, pantalla en negro con una R7 250X, el cual es un modelo equivalente a las Radeon HD 7770/8760. Vaya, pues qué mal porque Jessie está congelada. Convendría que os añadierais al informe de fallo de Debian para que vena que hay más gente afectada, a ver si lo pueden solucionar cuanto antes aunque el bug lo han marcado como upstream por lo que estarán esperando la respuesta o bien de AMD-ATI o bien de Xorg. He encontrado este bug, con los mismos síntomas que los tuyos (error con aiglx y pantalla en negro), echa un vistazo aunque no parece que esté solucionado: fglrx-driver: Black screen after xorg startup https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765109 Por lo que comentan y la salida que les devuelve, parece el mismo error que me aparece y lo único extraño que he visto es que los errores que se muestran en los que no parecen encontrar el archivo fglrx_dri.so, aparece en otras ubicaciones, esto es: /usr/lib/dri y en /usr/lib/x86_64-linux_gnu/dri Una persona de ese mismo hilo dice haber creado enlaces a los archivos sin conseguir que funciones y me pregunto si no será necesario añadir alguno más. No creo que el error venga de ahí. Como ya comenté antes en este hilo ese mensaje parece un falso positivo porque más tarde se activa la extensión AIGLX (aceleración 3D) sin problemas. En cualquier caso, que no se active el 3D no debería impedir que el sistema gráfico funciona, simplemente irá más lento en entornos que requieran aceleración. Si el driver cerrado no funciona puedes intentar cargar mientras tanto el radeon, digo, para poder ver algo al menos. Lamentablemente el driver radeon no funciona con esta tarjeta gráfica, al menos la versión que lleva Jessie. Desde que tengo esta gráfica he tenido que utilizar de manera forzosa el driver propietario y comenzé en Wheezy backports e instalando el driver desde testing. Lástima no haber visto este hilo antes o el problema que has mencionado, porque ahora tengo el equipo sin poder usarlo tras la actualización a Jessie. Vaya, pues qué mal... ¿seguro que tampoco funciona el driver radeon? Porque si es así también deberíais informar de eso o la gente que tenga una gráfica con ese chipset lo va a pasar muy mal con Jessie. Alguna idea para poder ir trabajando, a parte de redireccionar las X por ssh para arrancar los progranas que voy necesitando? Pues lo que dicen en el informe de fallo que es activar la tarjeta integrada (intel) aunque no sé si en vuestro caso tenéis sistemas gráficos híbridos y esto es una opción. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.14.50...@gmail.com
Re: ¿gdebi y shotwell autodesinstalables?
El Mon, 15 Dec 2014 19:34:49 +0100, Eduardo Rios escribió: El 14/12/14 a las 17:03, Camaleón escribió: (...) ¿Que hago? ¿Desinstalo, o ignoro el mensaje de autodesinstalable? Bueno, yo lo ignoraría de momento porque no sé qué quiere decir exactamente con audodesinstalable (traducción horrible, por cierto). Pasa olímpicamente de Synaptic y ejecuta mejor apt-get -f install a ver si éste se queja de algo y de qué, exactamente. Pongo enlace a una imagen. Siempre han dicho que una imagen vale más que mil palabras ;) http://picpaste.com/Synaptic-RIaXfmfT.png La imagen está muy bien aunque no era necesaria. Lo que sí echo en falta es la salida del comando apt-get -f install :-) En cualquier caso, los paquetes que se pueden eliminar (auto removable) son aquellos que se instalan indirectamente por otros paquetes (paquetes extra) y que una vez que se ha eliminado ese paquete que los necesitaba el gestor de paquetes los marca como autodesinstalables pero conviene revisarlos uno a uno por si acaso antes de eliminarlos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.02...@gmail.com
Re: Fwd: devuan
El Mon, 15 Dec 2014 20:21:42 -0300, Víctor Cana escribió: Buenas personal, Quiero decir que lo único que ha acontecido en base a todo este revuelo del systemd es que debian ha decidido hacer que systemd sea predeterminado en una instalación estándar. Bueno, eso no supone ningún problema y es forma parte del procedimiento habitual de Debian. Si bien, debian no obliga a nadie a usar systemd y siempre puedes instalar el sistema con el viejo sysvinit, con upstart, o con openRC como sistema de init. Debian no puede obligarte nunca a nada. Lo que sí puede (y es lo que ha hecho) es decirte que systemd es el gestor de servicios que va a tener el soporte al 100% mientras que el resto de servicios no se sabe exactamente con qué tipo de estatus cuenta. Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Entonces debian nos está dando una opción más con systemd, que es predeterminada, ok, al igual que es predeterminado el escritorio gnome y nadie está obligado a usarlo! Debian nos está dando para elegir 4 tipos de sistemas de init! no os ceguéis por lo predeterminado! No, creo que no has entendido el fondo de la problemática y sólo ves la superficie del problema. Lo único que depende de systemd son ciertos entornos de escritorio, y eso depende de sus desarrolladores, no es culpa de debian ni de systemd. Los entornos de escritorio no dependen de systemd (en todo caso algunas aplicaciones) y Debian podría haber optado por una solución lo suficientemente flexible como contentar a todos los usuarios, tanto a los que quieren usar systemd como los que no. En su lugar, han optado por una decisión salomónica que deja fuera de combate a una parte de su base de usuarios. Espero que no se resienta mucho. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.09...@gmail.com
Re: Sobre dns secundario
El Tue, 16 Dec 2014 09:03:50 -0500, Yaisel Cruz Zuñiga escribió: Llevo dias ya con una duda, tengo un servidor secundario dns (bind9) instalado en debian 7 y el servidor primario es un win2 server 2008, mi duda es la siguiente. Desde el servidor secundario se pueden modificar la zona ? En principio creo que no, la transferencia de datos es unidireccional (primario → secundario). Aunque según tengo entendido, a efectos prácticos la única diferencia entre un tipo y otro (primario/secundario) es el origen de dónde toma los datos del archivo de zonas: mientras que el servidor primario lo obtiene de manera local el secundario se nutre del servidor primario. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.21...@gmail.com
Re: Compilar U-boot(Bootloader) para ARMv5
El Mon, 15 Dec 2014 20:03:45 +0100, TheMrRafus a escribió: Hola Ese html... No se si sera aqui el sitio idoneo, pero dado que quiero compilarlo en un pc de 32 bits supongo qu ira aqui. El caso es que quiero compilar el bootloader U-Boot para el chipset Conexant CX 94610-11Z Supongo que necesito el Toolchain Linaro, hasta instalarlo se, lo que me falta son los comandos necesarios para compilarlo. (..) Mira a ver si esto te puede servir: https://wiki.linaro.org/Resources/HowTo/BootloaderDeploy Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.28...@gmail.com
Re: Sobre dns secundario
El dic 16, 2014 12:22 PM, Camaleón noela...@gmail.com escribió: El Tue, 16 Dec 2014 09:03:50 -0500, Yaisel Cruz Zuñiga escribió: Llevo dias ya con una duda, tengo un servidor secundario dns (bind9) instalado en debian 7 y el servidor primario es un win2 server 2008, mi duda es la siguiente. Desde el servidor secundario se pueden modificar la zona ? En principio creo que no, la transferencia de datos es unidireccional (primario → secundario). Aunque según tengo entendido, a efectos prácticos la única diferencia entre un tipo y otro (primario/secundario) es el origen de dónde toma los datos del archivo de zonas: mientras que el servidor primario lo obtiene de manera local el secundario se nutre del servidor primario. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.21...@gmail.com No imposible que desde un DNS secundario pretendas modificar zonas del primario por el simple hecho que uno es maestro y el otro un esclavo que como sentido el único propósito es equilibrar el tráfico de consulta que podría tener un solo servidor dns. Además que cuando el secundario recibe la transferencia de los datos para ser usada, esta solo queda en el secundario como de lectura. Ahora no entiendo por que te han dicho que el primario obtiene las zonas de forma local y el secundario desde el primario, que esto último es correcto. Pero de qué el dns primero la obtiene localmente... H deja decirte que esta mal por que podría suceder que no reciba ningún tipo de dato desde otros servidores dns. Saludos.
Re: Archivo no encontrado u oculto en memoria usb
El Tue, 16 Dec 2014 10:28:09 -0300, martin ayos escribió: El 16 de diciembre de 2014, 10:20, Pablo pablocar...@gmail.com escribió: Me respondo a mí mismo y agrego un dato que me parece sumamente raro: El archivo en cuestión sí aparece en Nautilus. Pero PCMan no lo muestra. No entiendo la razón. Gracias nuevamente. No si es el caso, pero a mi me sucedió varias veces que usando pcmanfm si no precionaba f5 no actualizaba bien los cambios en los archivos. Me sucedio en varias ocasiones. Puede que sea por eso. Gracias por la respuesta. La verdad es que no comprendo cuál será el motivo. Como te comenta Pablo, los administradores de archivos gráficos pueden ser problemáticos (bugs, caché...) por lo que antes de nada comprueba si efectivamente el archivo aparece en la llave (ls -la /media/llave_usb). También puedes probar a matar el proceso de pcmanfm (killall pcmanfm, ojo que ese comando te dejará sin escritorio, tendrás que volver a iniciarlo) para ver si volviendo a ejecutar el proceso aparece el archivo. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.40...@gmail.com
Re: cgroup y lxc
El Mon, 15 Dec 2014 19:13:24 +0100, José Miguel (sio2) escribió: El Mon, 15 de Dec de 2014, a las 04:06:45PM +, Camaleón dijo: Pues la verdad es que no :-P pero si no he entendido mal la problemática, te digo lo que probaría... 1/ Usuarios en lugar de grupos: perico:lxc-start * lxc/%u pantuflo:lxc-start * lxc/%u 2/ UID en lugar de nombres: @lxc:lxc-start * lxc/%U En realidad no parece que en ello esté el problema: de hecho, mientras uso sleep todo va bien. Es al usar lxc-start cuando se descuajeringa todo. No parece fallar cuando el criterio es simplemente @lxc * lxc/%u O sea, cualquier proceso que arranque un usuario que pertenezca a lxc, sea el que sea. Pero no he sido exhaustivo en las pruebas. (...) Entonces es posible que se deba al comando en sí mismo ¿que es lo que hace lxc-start exactamente? ¿necesita algún parámetro o se ejecuta directamente? ¿se puede ejecutar dentro de un contenedor lxc...? 3/ No sé si será posible pero sería interesante aumentar la verbosidad del registro para ver por qué no puede crear el contenedor (¿permisos?). No, no tiene nada que ver con permisos. Tiene que ver con que cgrulesengd deja de hacer su trabajo. Después de enviar el mensaje, arranqué el demonio cgrulesengd en primer plano y con el máximo de verborrea: # cgrulesengd -d Se puede ir viendo cómo el demonio analiza los procesos que ejecuto y comprueba si concuerdan o no con alguna regla de las escritas en /etc/cgrules.conf. Todo marcha bien, hasta que ejecuto lxc-start: ese proceso también sufre supervisión y aparentemente sin problemas, pero a partir de ese momento, el demonio se queda tonto: arranque lo que arranque después, no analiza nada. La consecuencia es que los procesos acaban en el cgroup que está el bash en que se ejecutan, o sea, el cgroup raíz. Tiene pinta de ser un bug. Acabo de hacer una consulta en la lista de usuarios de lxc. Como participan los desarrolladores, quizás me puedan arrojar luz sobre el asunto. A ver qué saco en claro. Como sea bug, mi gozo en un pozo, porque jessie ya está congelada. (...) Bueno, en Debian (y el resto de distribuciones) tienen especial interés en el uso de LXC, así que no me extrañaría que lo corrigieran antes de que salga Jessie, siempre y cuando se trate de un bug y el parche no sea excesivamente intrusivo para que no trastoque nada más. Ya nos contarás lo que te vayan diciendo. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.15.58...@gmail.com
Re: devuan
El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216171630.11fe6...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.16.40...@gmail.com
Re: servidor de correo electronico.
El 15/12/14, Ala de Dragón aladedra...@gmail.com escribió: (...) De momento voy a empaparme de dovecot y os voy contando. (...) Hola :D Estoy encajando las piezas del puzzle. SMTP funciona correctamente y entrega los correos a su destinatario. Puedo conectarme con mutt y leer los correos en /var/mail/usuario. Cuando me conecto a traves de telnet a POP3 Dovecot me da la bienvenida, y mi cliente de correo se conecta, autentifica y recibe una bandeja de entrada vacía. Voy a leer mas logs en profundidad pero parece que Dovecot busca los correos en otro lugar. Si la memoria no me falla creo haberle indicado que los almacenara en ~/mail Mi pregunta es: ¿que sintaxis debo utilizar para que busque los correos dovecot en /var/mail/usuario y no en su carpeta home, o como le indico a postfix que los entregue en ~/mail? Gracias por su tiempo ;) -- El cielo es para los dragones lo que el agua es para las ninfas -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+924hqjoymsmg+fypjawm3e1qf-_pzn5s8tp5nghhlg8es...@mail.gmail.com
Re: servidor de correo electronico.
Nosotros instalamos una suite muy buena en el e-mail del sur http://www.gentoo-es.com:2000/ Se llama Citadel, lo que no recuerdo el nombre del paquete. Yo me conecto a el Citadel por Sylpheed y por Seamonkey (mail) Simple, y en poco tiempo un excelente servidor de email. Saludos -- Servicios:. http://mamalibre.com.ar/plus MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina pgpzV9KKMfk4B.pgp Description: PGP signature
[OT] Es mejor un archivo grande o muchos pequeños
Saludos cordiales. Antes que nada me disculpo por el OT, pero es que no se donde o como buscar. El asunto es el siguiente: Estoy haciendo una aplicación que a su vez tiene varios hilos corriendo a la vez, estos hilos generan cierta informacion que necesito almacenar. He probado con SQLite, pero tengo problemas ya que algunas (muchas) veces cuando uno de los hilos de la aplicación necesita insertar información en la base de datos falla ya que se encuentra bloqueada por otro hilo. He subido el timeout pero solo ha mejorado un poco. Tambien tengo algo de temor ya que he leido que la base de datos podria corromporse si en un momento dos procesos escriben a la vez en la base de datos. Actualmente para este fin uso PostgreSQL, sin ningun problema, pero o que necesito es hacer la aplicacion mas independiente y facil de instalar, configurar, etc. He pensado en usar XML para cada registro que la aplicacion genera, de este modo ya no hay peligro de corrupcion de datos, como podria suceder en el caso de SQLite. La Pregunta es la siguiente: es pesado (lento) para el procesador el tener que leer o copiar cientos o miles de archivos individuales, lo pregunto porque me ha pasado que cuando copio alguna carpeta que contiene ciento de archivos, todos menores a 10K, el proceso es muy muy lento. Espero no molestar mucho con esta pregunta y ojala alguien me pueda dar una idea de que camino seguir. Gracias y saludos desde Ecuador. Mis proyectos de software libre en: Github - edwinspire
Re: devuan
El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. Saludos, Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216185350.43a9f...@gmail.com
Re: ¿gdebi y shotwell autodesinstalables?
El 16/12/14 a las 16:02, Camaleón escribió: El Mon, 15 Dec 2014 19:34:49 +0100, Eduardo Rios escribió: El 14/12/14 a las 17:03, Camaleón escribió: (...) ¿Que hago? ¿Desinstalo, o ignoro el mensaje de autodesinstalable? Bueno, yo lo ignoraría de momento porque no sé qué quiere decir exactamente con audodesinstalable (traducción horrible, por cierto). Pasa olímpicamente de Synaptic y ejecuta mejor apt-get -f install a ver si éste se queja de algo y de qué, exactamente. Pongo enlace a una imagen. Siempre han dicho que una imagen vale más que mil palabras ;) http://picpaste.com/Synaptic-RIaXfmfT.png La imagen está muy bien aunque no era necesaria. Lo que sí echo en falta es la salida del comando apt-get -f install :-) Cierto, se me pasó. Aquí está: root@debian:/home/edurios# apt-get -f install Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho Los paquetes indicados a continuación se instalaron de forma automática y ya no son necesarios. gdebi libgexiv2-2 shotwell shotwell-common Utilice «apt-get autoremove» para eliminarlos. 0 actualizados, 0 nuevos se instalarán, 0 para eliminar y 0 no actualizados. root@debian:/home/edurios# Como ves, los mismos paquetes que me indica synaptic como autoeliminables En cualquier caso, los paquetes que se pueden eliminar (auto removable) son aquellos que se instalan indirectamente por otros paquetes (paquetes extra) y que una vez que se ha eliminado ese paquete que los necesitaba el gestor de paquetes los marca como autodesinstalables pero conviene revisarlos uno a uno por si acaso antes de eliminarlos. Así es, indica que se fueron instalados de forma automática. Entiendo que tanto gdebi como shotwell fueron instalados por gnome, y por eso me extraña que ya no los necesite... porque gdebi es para instalar paquetes, y shotwell un visor de imágenes... por lo que no entiendo que ahora se puedan quitar sin más y antes no. -- www.LinuxCounter.net Registered user #558467 has 2 linux machines -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m6prlr$jg1$1...@ger.gmane.org
Re: devuan
El 16/12/14 a las 18:53, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. Saludos, Saludos. No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. Y si es así, tiene razón Camaleon al decir que los usuarios que no usen systemd van a estar vendidos. ¿Es así, no? -- www.LinuxCounter.net Registered user #558467 has 2 linux machines -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m6psgd$4b2$1...@ger.gmane.org
Re: servidor de correo electronico.
El martes, 16 dic 2014, a las 18:43 horas (UTC+1), Ala de Dragón escribió: ¿que sintaxis debo utilizar para que busque los correos dovecot en /var/mail/usuario y no en su carpeta home, o como le indico a postfix que los entregue en ~/mail? Para lo primero, ajusta el parámetro de configuración mail_location Viene en la documentación de Dovecot. Lo segundo lo puedes hacer ajustando la variable de entorno de usuario MAIL (hablamos de buzones de usuarios de sistema, no buzones virtuales, ¿verdad?). Supongo que es más cómodo el método primero. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216191632.00825...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 18:53:50 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete del que estamos hablando: un bug en el gestor de servicios (o en un servicio que no se inicia con sysvinit) no tiene el mismo impacto que un bug en una aplicación cualquiera. En el primer caso te puedes quedar sin iniciar el sistema mientras que en el segundo a lo sumo te quedas sin poner iniciar una aplicación. Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Estamos hablando de un hipotético bug que exista en los paquetes que sustituyen o reemplazan a systemd (upstart, sysvinit), es decir, paquetes que sí existen y no están obsoletos ni abandonados. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. No estamos hablando de esa situación. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.18.16...@gmail.com
Re: ¿gdebi y shotwell autodesinstalables?
El Tue, 16 Dec 2014 18:55:08 +0100, Eduardo Rios escribió: El 16/12/14 a las 16:02, Camaleón escribió: (...) Cierto, se me pasó. Aquí está: root@debian:/home/edurios# apt-get -f install Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho Los paquetes indicados a continuación se instalaron de forma automática y ya no son necesarios. gdebi libgexiv2-2 shotwell shotwell-common Utilice «apt-get autoremove» para eliminarlos. 0 actualizados, 0 nuevos se instalarán, 0 para eliminar y 0 no actualizados. root@debian:/home/edurios# Como ves, los mismos paquetes que me indica synaptic como autoeliminables Sí, exacto. En cualquier caso, los paquetes que se pueden eliminar (auto removable) son aquellos que se instalan indirectamente por otros paquetes (paquetes extra) y que una vez que se ha eliminado ese paquete que los necesitaba el gestor de paquetes los marca como autodesinstalables pero conviene revisarlos uno a uno por si acaso antes de eliminarlos. Así es, indica que se fueron instalados de forma automática. Entiendo que tanto gdebi como shotwell fueron instalados por gnome, y por eso me extraña que ya no los necesite... porque gdebi es para instalar paquetes, y shotwell un visor de imágenes... por lo que no entiendo que ahora se puedan quitar sin más y antes no. Sí que es raro, porque al menos gdebi y shotwell los tengo por aplicaciones autónomas, no dependientes de otros paquetes :-? Mira a ver si aptitude why-not gdebi te da más detalles aunque no sé si funcionará con ese tipo de marca. Lo que sí podrás hacer es quitarles el sambenito de ser eliminables desde aptitude cambiando su estado. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.18.23...@gmail.com
Re: ¿gdebi y shotwell autodesinstalables?
El martes, 16 dic 2014, a las 19:23 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 18:55:08 +0100, Eduardo Rios escribió: El 16/12/14 a las 16:02, Camaleón escribió: En cualquier caso, los paquetes que se pueden eliminar (auto removable) son aquellos que se instalan indirectamente por otros paquetes (paquetes extra) y que una vez que se ha eliminado ese paquete que los necesitaba el gestor de paquetes los marca como autodesinstalables pero conviene revisarlos uno a uno por si acaso antes de eliminarlos. Así es, indica que se fueron instalados de forma automática. Entiendo que tanto gdebi como shotwell fueron instalados por gnome, y por eso me extraña que ya no los necesite... porque gdebi es para instalar paquetes, y shotwell un visor de imágenes... por lo que no entiendo que ahora se puedan quitar sin más y antes no. Sí que es raro, porque al menos gdebi y shotwell los tengo por aplicaciones autónomas, no dependientes de otros paquetes :-? $ apt-cache rdepends gdebi shotwell gdebi Reverse Depends: python-vte python-apt education-common cinnamon-desktop-environment aptoncd shotwell Reverse Depends: shotwell-dbg shotwell-common shotwell-common shotwell-common libgexiv2-2 cinnamon-desktop-environment Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216193534.3eba5...@gmail.com
Re: servidor de correo electronico.
El 16/12/14, Manolo Díaz diaz.man...@gmail.com escribió: El martes, 16 dic 2014, a las 18:43 horas (UTC+1), Para lo primero, ajusta el parámetro de configuración mail_location Viene en la documentación de Dovecot. http://wiki2.dovecot.org/MailLocation La he leido varias veces. la cuestion es que no se definir usuario como variable en mail_location = mbox:~/mail:INBOX=/var/mail/%u ¿es el %u la variable? Lo segundo lo puedes hacer ajustando la variable de entorno de usuario MAIL (hablamos de buzones de usuarios de sistema, no buzones virtuales, ¿verdad?). Supongo que es más cómodo el método primero. de sistema. Saludos. -- Manolo Díaz Gracias Manolo :) -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216191632.00825...@gmail.com -- El cielo es para los dragones lo que el agua es para las ninfas -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+924HQ_Tu=dgmt1gkaewabxbyt5fjx31+rst1uxjs+pwpb...@mail.gmail.com
Re: devuan
El Tue, 16 Dec 2014 19:09:18 +0100, Eduardo Rios escribió: El 16/12/14 a las 18:53, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: (...) Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Y por lo que sé, únicamente se ha abandonado un paquete cuando es obsoleto e inservible, o cuando casi nadie lo usa y no hay mantenedor dispuesto a hacerse cargo. No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. Y si es así, tiene razón Camaleon al decir que los usuarios que no usen systemd van a estar vendidos. ¿Es así, no? Sí, así lo veo yo y no encuentro nada malo en esa decisión (cada uno tomará las contramedidas que estime oportunas), lo que me molesta es que pretendan vendernos otra cosa cuando todos sabemos que no va a ser así. Un proyecto como Debian tiene que tomar sus propias decisiones pero lo que no se espera es la falta de transparencia. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.18.37...@gmail.com
Re: servidor de correo electronico.
El Tue, 16 Dec 2014 18:43:16 +0100, Ala de Dragón escribió: El 15/12/14, Ala de Dragón aladedra...@gmail.com escribió: (...) De momento voy a empaparme de dovecot y os voy contando. (...) Hola :D Estoy encajando las piezas del puzzle. SMTP funciona correctamente y entrega los correos a su destinatario. Puedo conectarme con mutt y leer los correos en /var/mail/usuario. Cuando me conecto a traves de telnet a POP3 Dovecot me da la bienvenida, y mi cliente de correo se conecta, autentifica y recibe una bandeja de entrada vacía. Voy a leer mas logs en profundidad pero parece que Dovecot busca los correos en otro lugar. Si la memoria no me falla creo haberle indicado que los almacenara en ~/mail ~/mail es /home/$USER/mail, así que si le has dicho a Dovecot que los mensajes vayan ahí, ahí es donde estarán. Mi pregunta es: ¿que sintaxis debo utilizar para que busque los correos dovecot en /var/mail/usuario y no en su carpeta home, o como le indico a postfix que los entregue en ~/mail? Pues según la documentación¹, la variable que controla el tipo de buzón (mbox o maildir) y su ubicación es mail_location. Mira a ver qué tienes definido. Ahora bien, como te comenté anteriormente, tienes que decidir quién lleva la carga de trabajo, Postfix o Dovecot y en base a esa decisión ajustar la variable en el archivo de configuración de uno u otro. ¹http://wiki2.dovecot.org/FindMailLocation Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.18.45...@gmail.com
Re: servidor de correo electronico.
El 16/12/14, Fabián Bonetti mama21m...@riseup.net escribió: Nosotros instalamos una suite muy buena en el e-mail del sur http://www.gentoo-es.com:2000/ Se llama Citadel, lo que no recuerdo el nombre del paquete. Yo me conecto a el Citadel por Sylpheed y por Seamonkey (mail) Simple, y en poco tiempo un excelente servidor de email. Saludos Una suite excelente, simple y potente. La estudiare por curisidad. Parece que trabaja con berkley DB Para este caso demasiado compleja. Gracias por el apunte ;) http://www.citadel.org/doku.php/documentation:system_administration_manual https://packages.debian.org/wheezy/citadel-suite -- El cielo es para los dragones lo que el agua es para las ninfas -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+924hrmrygmcxo9qjw_mfcpaj+drmundcdwbos7yxhsb4r...@mail.gmail.com
Re: devuan
El martes, 16 dic 2014, a las 19:16 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 18:53:50 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 17:40 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 17:16:30 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 16:09 horas (UTC+1), Camaleón escribió: Es decir, que los problemas derivados de usar sysvinit se podrían rechazar/cerrar sin más en los informes de fallo dejando a los usuarios sin plena cobertura. Solo he visto que se dé ese caso cuando un paquete es expulsado del repositorio y ya no es mantenido, lo cuál tiene toda la lógica del mundo. El problema es que depende completamente del empaquetador/mantenedor, y los hay que son un poco toca-narices (no sólo en Debian, ojo). No es la primera vez que un bug termina a debate en el CTTE porque el mantenedor de turno se enroca en una postura absurda y no hay quien lo saque de ahí. Pero eso es general y válido para los más de 40.000 paquetes existentes. Aunque sería interesante saber cómo proceder en casos así... El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete del que estamos hablando: un bug en el gestor de servicios (o en un servicio que no se inicia con sysvinit) no tiene el mismo impacto que un bug en una aplicación cualquiera. En el primer caso te puedes quedar sin iniciar el sistema mientras que en el segundo a lo sumo te quedas sin poner iniciar una aplicación. Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. Para empeorar las cosas, con la excusa de que systemd es el sistema predeterminado en Jessie y de la reciente votación de no es necesario incidir en este punto pues deja todo en el aire, sin ningún tipo de garantía de cara al administrador que vaya a instalar Debian Jessie y que no quiera usar systemd. Y ni siquiera en ese caso lo cierran sin más: los informadores son debidamente notificados sobre por qué se cierran. Pues qué bien ¿y de qué sirve que te digan que lo cierran porque quieren? Pues de nada, es más, te deja peor el cuerpo. No, no es que lo cierren porque quieren. Lo cierran porque es absurdo tener abierto informes de fallos sobre un paquete que ya no existe (salvo en snapshot). En ese caso, además, recibes una notificación automática explicando el porqué. Estamos hablando de un hipotético bug que exista en los paquetes que sustituyen o reemplazan a systemd (upstart, sysvinit), es decir, paquetes que sí existen y no están obsoletos ni abandonados. Pues lo habitual es justo lo contrario a tus temores, que los paquetes cruciales consigan más atención, no menos, que el resto. De hecho, en esos casos suelen considerar fallos de nivel importante como si fuesen RC. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216195516.7d07a...@gmail.com
Re: servidor de correo electronico.
El martes, 16 dic 2014, a las 19:37 horas (UTC+1), Ala de Dragón escribió: El 16/12/14, Manolo Díaz diaz.man...@gmail.com escribió: El martes, 16 dic 2014, a las 18:43 horas (UTC+1), Para lo primero, ajusta el parámetro de configuración mail_location Viene en la documentación de Dovecot. http://wiki2.dovecot.org/MailLocation La he leido varias veces. la cuestion es que no se definir usuario como variable en mail_location = mbox:~/mail:INBOX=/var/mail/%u ¿es el %u la variable? Sí. %u es sustituido en cada caso por el nombre de usuario correspondiente. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216195735.53515...@gmail.com
Re: devuan
El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. Y si es así, tiene razón Camaleon al decir que los usuarios que no usen systemd van a estar vendidos. ¿Es así, no? Si vendido significa un futuro sin otro sistema de inicio en Debian, pudiera ser. Si significa que van a haber otros sistemas de inicio pero que van a estar plagados de fallos... bueno, en el mejor de los casos eso es hablar por hablar. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216203257.631ca...@gmail.com
Re: servidor de correo electronico.
El 16/12/14, Camaleón noela...@gmail.com escribió: ~/mail es /home/$USER/mail, así que si le has dicho a Dovecot que los mensajes vayan ahí, ahí es donde estarán. Gracias, ya lo he cambiado :) (...) El 16/12/14, Manolo Díaz diaz.man...@gmail.com escribió: (...) Sí. %u es sustituido en cada caso por el nombre de usuario correspondiente. Ahora lo en tiendo perfectamente. Una vez corregido funciona correctamente. (...) Gracias :) -- El cielo es para los dragones lo que el agua es para las ninfas -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+924hsdbfegjp6yjmpqpbfgdawfxu0oqzyymwm-5oa15ww...@mail.gmail.com
Re: [OT] Es mejor un archivo grande o muchos pequeños
El 16/12/14, Edwin De La Cruz edwinsp...@gmail.com escribió: (...) La Pregunta es la siguiente: es pesado (lento) para el procesador el tener que leer o copiar cientos o miles de archivos individuales, lo pregunto porque me ha pasado que cuando copio alguna carpeta que contiene ciento de archivos, todos menores a 10K, el proceso es muy muy lento. (...) Hola :) Yo probaría cambiar y configurar el sistema de ficheros, tamaño de inodos etc... Reiserfs tiene muy buena fama con ficheros pequeños. http://www.buanzo.com.ar/lin/70s-FStrans.html Saludos. -- El cielo es para los dragones lo que el agua es para las ninfas -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+924HRuozGDZh7S25Hdr37AY=z2xzbsbb+j0xctjbvoemd...@mail.gmail.com
Re: Fwd: fglrx-driver
El 16/12/2014 15:51, Camaleón noela...@gmail.com escribió: El Mon, 15 Dec 2014 19:18:03 +0100, Javier Silva escribió: (ese html...) Lamento lo del html, pero me he quedado sin equipo y contesto desde el móvil y el maravilloso gmail no me deja responder en solo texto :-( y eso que lo he pedido como 2 millones de veces. El 14/12/2014 17:20, Camaleón noela...@gmail.com escribió: Hola a todos, También tengo el mismo problema, pantalla en negro con una R7 250X, el cual es un modelo equivalente a las Radeon HD 7770/8760. Vaya, pues qué mal porque Jessie está congelada. Convendría que os añadierais al informe de fallo de Debian para que vena que hay más gente afectada, a ver si lo pueden solucionar cuanto antes aunque el bug lo han marcado como upstream por lo que estarán esperando la respuesta o bien de AMD-ATI o bien de Xorg. Lamentablemente el driver radeon no funciona con esta tarjeta gráfica, al menos la versión que lleva Jessie. Desde que tengo esta gráfica he tenido que utilizar de manera forzosa el driver propietario y comenzé en Wheezy backports e instalando el driver desde testing. Lástima no haber visto este hilo antes o el problema que has mencionado, porque ahora tengo el equipo sin poder usarlo tras la actualización a Jessie. Vaya, pues qué mal... ¿seguro que tampoco funciona el driver radeon? Porque si es así también deberíais informar de eso o la gente que tenga una gráfica con ese chipset lo va a pasar muy mal con Jessie. El driver radeon no ha funcionado nunca con estas series de tarjetas y así lo indica la lista de chips soportados y estos no aparecen. Alguna idea para poder ir trabajando, a parte de redireccionar las X por ssh para arrancar los progranas que voy necesitando? Pues lo que dicen en el informe de fallo que es activar la tarjeta integrada (intel) aunque no sé si en vuestro caso tenéis sistemas gráficos híbridos y esto es una opción. No tengo tarjeta integrada intel, mi sistema es un AMD Phenom II con un zócalo AM3+ sin IGP, por lo que sólo dispongo de esta gráfica. Curiosamente la última live de GNOME sí que funciona perfectamente y sin el driver propietario. Tenía que haber seguido con Wheezy backports y el driver de testing que sí funcionaba perfectamente, ahora me tocará volver de nuevo a Wheezy si no encuentro una solución. Saludos, Javier.
Re: [OT] Es mejor un archivo grande o muchos pequeños
El 16 de diciembre de 2014, 16:44, Ala de Dragón aladedra...@gmail.com escribió: El 16/12/14, Edwin De La Cruz edwinsp...@gmail.com escribió: (...) La Pregunta es la siguiente: es pesado (lento) para el procesador el tener que leer o copiar cientos o miles de archivos individuales, lo pregunto porque me ha pasado que cuando copio alguna carpeta que contiene ciento de archivos, todos menores a 10K, el proceso es muy muy lento. (...) Hola :) Yo probaría cambiar y configurar el sistema de ficheros, tamaño de inodos etc... Reiserfs tiene muy buena fama con ficheros pequeños. http://www.buanzo.com.ar/lin/70s-FStrans.html Saludos. -- El cielo es para los dragones lo que el agua es para las ninfas -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+924hruozgdzh7s25hdr37ayz2xzbsbb+j0xctjbvoemd...@mail.gmail.com Gracias por responder, el problema de hacer esa eleccion es que la aplicacion tambien la tengo pensada para correr en Winbugs. De momento usando SQLite, segun he leido, el sistema de bloqueo de archivos funciona bien en Linux, pero en winbugs es otro cosa. He ahi mi temor. Tengo pensado algo un poco descabellado: 1- Que la aplicacion guarde los registros en XML individuales. 2- Al arrancar la aplicacion se crearia una base de datos SQLite en memoria que automaticamente carge todos esos registros en la base, para que pueda ser facil acceder a ellos por SQL. 3- Cuando un nuevo registro es creado, automaticamente se crea un XML y se inserta en la base de datos. De este modo creo que si la base de datos SQLite se corrompe no habria problema, puesto que al reiniciar la aplicacion esta crearia la base de datos nuevamente.
Re: devuan
2014-12-16 13:55 GMT-05:00 Manolo Díaz diaz.man...@gmail.com: ... Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. La idea es minimizar el número de puntos únicos de fallo[0]. Añadir uno más es añadir más eslabones a la cadena, lo que significa aumentar la probabilidad de que un eslabón pueda fallar y ya conoces el dicho: una cadena es tan fuerte como el eslabon más debil. [0] https://es.wikipedia.org/wiki/Single_point_of_failure -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caabycjpnbo2b2oweycur9ze-yma1krm6vs-2pyag4yvvtmy...@mail.gmail.com
Re: devuan
El martes, 16 dic 2014, a las 23:25 horas (UTC+1), Carlos Zuniga escribió: 2014-12-16 13:55 GMT-05:00 Manolo Díaz diaz.man...@gmail.com: ... Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. La idea es minimizar el número de puntos únicos de fallo[0]. Añadir uno más es añadir más eslabones a la cadena, lo que significa aumentar la probabilidad de que un eslabón pueda fallar y ya conoces el dicho: una cadena es tan fuerte como el eslabon más debil. [0] https://es.wikipedia.org/wiki/Single_point_of_failure Muy bien, pero cambiar un sistema de inicio por otro no es añadir. El número de puntos únicos de fallo sigue siendo el mismo. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216233622.06800...@gmail.com
Re: [OT] Es mejor un archivo grande o muchos pequeños
2014-12-16 16:56 GMT-05:00 Edwin De La Cruz edwinsp...@gmail.com: El 16 de diciembre de 2014, 16:44, Ala de Dragón aladedra...@gmail.com escribió: El 16/12/14, Edwin De La Cruz edwinsp...@gmail.com escribió: (...) La Pregunta es la siguiente: es pesado (lento) para el procesador el tener que leer o copiar cientos o miles de archivos individuales, lo pregunto porque me ha pasado que cuando copio alguna carpeta que contiene ciento de archivos, todos menores a 10K, el proceso es muy muy lento. (...) Hola :) Yo probaría cambiar y configurar el sistema de ficheros, tamaño de inodos etc... Reiserfs tiene muy buena fama con ficheros pequeños. http://www.buanzo.com.ar/lin/70s-FStrans.html Saludos. Gracias por responder, el problema de hacer esa eleccion es que la aplicacion tambien la tengo pensada para correr en Winbugs. De momento usando SQLite, segun he leido, el sistema de bloqueo de archivos funciona bien en Linux, pero en winbugs es otro cosa. He ahi mi temor. Tengo pensado algo un poco descabellado: 1- Que la aplicacion guarde los registros en XML individuales. 2- Al arrancar la aplicacion se crearia una base de datos SQLite en memoria que automaticamente carge todos esos registros en la base, para que pueda ser facil acceder a ellos por SQL. 3- Cuando un nuevo registro es creado, automaticamente se crea un XML y se inserta en la base de datos. De este modo creo que si la base de datos SQLite se corrompe no habria problema, puesto que al reiniciar la aplicacion esta crearia la base de datos nuevamente. Has leido la documentación de sqlite sobre su uso con mutiples threads[0]? Según indican funciona bien, pero tienes que especificar que quieres la funcionalidad multi-thread ya sea durante la compilación o mediante una configuración al iniciar. Eso, y cada thread debe usar su propia conexión. Dicho eso, no me gusta sqlite más que para cosas simples donde no importa mucho si la data se corrompe, te recomendaría postgres si no fuera por que eso es lo que ya estas usando. Si solo quieres usar la base de datos como una cache en memoria, tal vez te convendría mejor algo como redis que esta hecho con ese propósito en lugar de sqlite. Saludos [0] https://sqlite.org/threadsafe.html -- A menudo unas pocas horas de Prueba y error podrán ahorrarte minutos de leer manuales. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caabycjnf8sguz0lqtao9bxpim6tuzkohpfgyvequd9a0uhe...@mail.gmail.com
Re: [OT] Es mejor un archivo grande o muchos pequeños
Gracias. Voy a leer un poco más de información. Proyectos personajes de desarrollo de software: github.com/edwinspire Enviado desde Samsung Mobile El 16/12/2014 17:58, Carlos Zuniga carlos@gmail.com escribió: 2014-12-16 16:56 GMT-05:00 Edwin De La Cruz edwinsp...@gmail.com: El 16 de diciembre de 2014, 16:44, Ala de Dragón aladedra...@gmail.com escribió: El 16/12/14, Edwin De La Cruz edwinsp...@gmail.com escribió: (...) La Pregunta es la siguiente: es pesado (lento) para el procesador el tener que leer o copiar cientos o miles de archivos individuales, lo pregunto porque me ha pasado que cuando copio alguna carpeta que contiene ciento de archivos, todos menores a 10K, el proceso es muy muy lento. (...) Hola :) Yo probaría cambiar y configurar el sistema de ficheros, tamaño de inodos etc... Reiserfs tiene muy buena fama con ficheros pequeños. http://www.buanzo.com.ar/lin/70s-FStrans.html Saludos. Gracias por responder, el problema de hacer esa eleccion es que la aplicacion tambien la tengo pensada para correr en Winbugs. De momento usando SQLite, segun he leido, el sistema de bloqueo de archivos funciona bien en Linux, pero en winbugs es otro cosa. He ahi mi temor. Tengo pensado algo un poco descabellado: 1- Que la aplicacion guarde los registros en XML individuales. 2- Al arrancar la aplicacion se crearia una base de datos SQLite en memoria que automaticamente carge todos esos registros en la base, para que pueda ser facil acceder a ellos por SQL. 3- Cuando un nuevo registro es creado, automaticamente se crea un XML y se inserta en la base de datos. De este modo creo que si la base de datos SQLite se corrompe no habria problema, puesto que al reiniciar la aplicacion esta crearia la base de datos nuevamente. Has leido la documentación de sqlite sobre su uso con mutiples threads[0]? Según indican funciona bien, pero tienes que especificar que quieres la funcionalidad multi-thread ya sea durante la compilación o mediante una configuración al iniciar. Eso, y cada thread debe usar su propia conexión. Dicho eso, no me gusta sqlite más que para cosas simples donde no importa mucho si la data se corrompe, te recomendaría postgres si no fuera por que eso es lo que ya estas usando. Si solo quieres usar la base de datos como una cache en memoria, tal vez te convendría mejor algo como redis que esta hecho con ese propósito en lugar de sqlite. Saludos [0] https://sqlite.org/threadsafe.html -- A menudo unas pocas horas de Prueba y error podrán ahorrarte minutos de leer manuales. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caabycjnf8sguz0lqtao9bxpim6tuzkohpfgyvequd9a0uhe...@mail.gmail.com
fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... P.D.: Se pueden imaginar como estoy putenado a red hat y systemd no? Saludos desde el sur. P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5490d933.6050...@gmail.com
fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resultado de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... P.D.: Se pueden imaginar como estoy puteando a red hat y systemd no? Saludos desde el sur. P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin ingreasar en el... -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5490dc9a.2020...@gmail.com
Habilitar USB en Clientes Ligeros debian wheezy
Hola lista tengo un servidor de clientes ligeros montado en debian wheezy, me funciona correctamente pero no puedo conectar dispositivos USB en los clientes. ¿Cómo puedo hacerlo? gracias de antemano -- Saludos Lic. Didier E. Suárez Rodríguez Especalista en Ciencias Informáticas-Administrador de Red Dirección de Gestión de la Información Científica Universidad de Camaguey Ignacio Agramonte Loynaz Cuba En Intranet del MES: http://web.cgi.reduc.edu.cu En Internet: http://www.reduc.edu.cu/cgi Catálogo en Intranet: http://abcd.reduc.edu.cu/site -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5490e471.3030...@reduc.edu.cu
Systemd y kernel 3.16.0.4 - Fallo al iniciar sistema - jessie
La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... P.D.: Se pueden imaginar como estoy puteando a red hat y systemd no? Saludos desde el sur. P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribilo sin ingresar al mismo... -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5490f15c.7050...@gmail.com
