Re: OT: Hay futuro más allá de Jessie
El martes, 11 nov 2014 a las 08:37 horas (UTC+1), C. L. Martinez escribió: 2014-11-10 18:15 GMT+00:00 Santiago Vila sanv...@unex.es: On Mon, Nov 10, 2014 at 02:45:25PM +, Camaleón wrote: A mí personalmente me está asustando el grado de dependencia que el kernel está haciendo de systemd. Supone tal vez Camaleón que la gente del núcleo, después de ponerle la característica cgroups (en la que se basa systemd) tendría que haber dicho Pero esta característica no es para usarla, ¿eh? Es solamente de adorno. Lo del systemd con el kernel no es un adorno, es la mayor cagada que le conozco a Linux en los más de 15 años que llevo usándolo. De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, porque es algo que no me entra en la cabeza. Muy errónea tiene que ser la vaga idea que tengo de núcleo para que eso sea posible. El tema de los escritorios, etc. es otro cantar muy distinto. Si systemd se dedicase a controlar los servicios en el arranque (que és para lo que fue parido), sin lugar a dudas es la mejor opción técnica que existe por delante de todas: openrc, uselessd, etc. Porque eso, si reconozco que lo hace perfecto, con el control de dependencias y demás. Mira, ahí estoy de acuerdo. También a mí me hubiese gustado que systemd se conformase con iniciar el espacio de usuario y controlar los servicios de arranque. Mucho más fiable el control basado en cgroups que el truco de guardar el pid del proceso. Dicho sea de paso: SysV tampoco es mi ideal. Quizá algún día que me sienta menos perezoso pruebe upstart. [...] 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/2014091209.301b3...@gmail.com
Re: Partición pierde UUID
El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: (...) La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. ¿Cómo que se pierde el UUID? Es que si no nos dices el resultado del comando que te puse no queda nada claro lo que dices ni a lo que te refieres. Pero aún así, aunque el identificador uuid de la partición de arranque esté en blanco o no exista puedes usar el identificador que prefieras, eso es indiferente. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Por ejemplo, o puedes usar ID o label. Lo que tampoco me termina de quedar claro es por qué asignando el uuid a la partición de arranque (el mismo u otro) dices que no corrige el problema. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing 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.11.10.14.38...@gmail.com Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. -- 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/e2cbef9f-960e-4f64-afc5-c4220e0a9...@gmail.com
Re: BTRFS en la próxima Debian Stable
El 10/11/2014, a las 12:15, Luis Felipe Tabera Alonso lftab...@yahoo.es escribió: On Monday 10 November 2014 10:43:45 ZorroPlateado wrote: Alguien sabe o donde puedo encontrar información al respecto , estoy interesado en saber si dicho sistema de ficheros va a ser soportado y en qué grado. Yo te puedo decir que uso ahora debian testing y que he migrado recientemente tres instalaciones de ext4 a btrfs y funciona sin problemas. Necesitas btrfs- tools para tener las utilidades del espacio de usuario. Yo personalmente no me atrevería a meterlo todavía en un servidor en producción todavía, pero sin problemas para un desktop de uso personal. En la primera instalación que hice, por si acaso, creé una partición separada /boot con ext4. En las otras dos no tengo partición /boot separada (arranca directamente en btrfs). Cosas que uso y me funcionan: - Montar con las opciones de comprimir datos dee manera transparente y autodefrag. - Raid 1 con dos discos. - Crear snapshots y subvolumenes. - Hacer un scrub en los datos y metadatos para comprobar la consistencia. - Deduplicación (usando bedup, no incluído en debian). (Aunque no se si la deduplicación la hace solo cuando los checksums coinciden o mira bit a bit, ahí habría una probabilidad muy baja de perdida de datos). - También he probado a montar un solo disco del Raid 1 en modo degradado, escribir en el disco bastantes datos y luego montar el raid completo y pasarle un checking para que me arregle el Raid. No he probado Raid0 ni el 10 Recuerda que los modos Raid 5/6 aún no están terminados. Para hacer backups uso rsync, todavía no he probado btrfs send/receive y no creo que lo haga en un espacio corto de tiempo. Btrfs es más lento en lectura/escritura que ext4. Por ejemplo apt-get es muucho más lento. (Busca por las palabras btrfs slow apt-get eatmydata). Luis -- 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/3197479.V4ddzWVk6f@mychabol Hace unos días he visto un artículo de Phoronix donde Fujitsu segundo gran aportador al código de btrfs indica todos los tests que ha hecho y el uso que hacen en servidor de misión crítica, lo cuál me sorprende. Más aún men sorprende que los chicos de RedHat hayan invertido todo su esfuerzo en la release 7 hacia el uso por defecto de XFS cuando btrfs va a ser el verdadero sucesor de ext4. Y la verdad quiero quitarme toda la complejidad de la combinación ext4+LVM, veo a btrfs como el ZFS para Linux, y ya sé que existe un proyecto para llevar ZFS a Linux pero por su licencia nunca será integrado en kernel. Lo que me gustaría ver es una release notes de la próxima versión Debian donde indiquen si se aconseja el uso en la distro o como un preview. -- 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/72b8948c-d67f-4766-a7df-c50c23380...@gmail.com
Re: BTRFS en la próxima Debian Stable
El 10/11/2014, a las 15:55, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 10:43:45 +0100, ZorroPlateado escribió: Alguien sabe o donde puedo encontrar información al respecto , estoy interesado en saber si dicho sistema de ficheros va a ser soportado y en qué grado. En openSUSE ya lo han incluido como sistema de archivos predeterminado y ya está siendo recomendado por los propios desarrolladores para instalaciones de todo tipo (eso sí, sólo raid de niveles 1/10 pero no 5/6) junto con el kernel estable más reciente. En cuanto a Jessie no he leído nada en concreto sobre BTRFS en las notas de la versión¹ así que supongo que el soporte será el habitual, es decir, estará disponible para usar pero no será la opción predeterminada y que irá en función de la versión del kernel que se instale. ¹https://www.debian.org/releases/jessie/amd64/release-notes/index.en.html Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.10.14.55...@gmail.com Acabo de verlo en esa url: Default filesystem ext4 is the default filesystem for new installations, replacing ext3. The btrfs filesystem is provided as a technology preview. -- 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/3e3c705e-7621-4d78-b094-0bbe9a2bb...@gmail.com
Re: Problemas con libaudio2_1.9.4-1+b1_amd64.deb
On Monday 10 November 2014 21:12:58 Eduardo Rios wrote: El 10/11/14 a las 12:42, Debian GMail escribió: Tener cuidado al actualizar Jessie (testing) amd64. Ya me pasó a mí. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768651 JAP Yo actualicé este paquete (y otros muchos) y no me dio error alguno (o no me di cuenta) ¿Como puedo saber si está instalado correctamente? Gracias El bug solo surge si tienes instalado tanto la versión de 64 como 32 bits ya que hay ficheros distintos en común entre los dos paquetes que no están bien manejados. Si no te dio error no hay razones para suponer que está mal instalado. Luis -- 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/3650970.D2MXDmNAX7@mychabol
Re: OT: Hay futuro más allá de Jessie
On Tue, Nov 11, 2014 at 09:12:09AM +0100, Manolo Díaz wrote: De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, [...] Linux no depende de systemd. La dependencia es al revés: systemd utiliza cgroups, que es una característica de Linux. Por este motivo systemd no es fácilmente portable a otros núcleos. -- 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/2014092522.ga2...@cantor.unex.es
Re: Problemas con libaudio2_1.9.4-1+b1_amd64.deb [SOLUCIONADO]
El 10/11/14 a las 08:42, Debian GMail escibió: Tener cuidado al actualizar Jessie (testing) amd64. Ya me pasó a mí. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768651 JAP Bien. Fue relativamente fácil, por lo menos, en esta máquina. Con apt no lo pudo solucionar, pero sí con aptitude. Los pasos fueron # aptitude -f install lo que eliminó unos cuantos archivos, sobre todo librerías, y, cosa rara, ssh openssh-server vlc Una vez ejecutado, procedí a la actualización como siempre con # apt-get upgrade y luego # apt-get install ssh openssh-server vlc para recuperar los paquetes perdidos. Ya está estabilizado el sistema de paquetes. Tal vez apt-get se esté poniendo viejo. JAP -- 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/5462071e.9080...@gmail.com
Re: OT: Hay futuro más allá de Jessie
El Tue, 11 Nov 2014 09:12:09 +0100, Manolo Díaz escribió: El martes, 11 nov 2014 a las 08:37 horas (UTC+1), C. L. Martinez escribió: (...) Lo del systemd con el kernel no es un adorno, es la mayor cagada que le conozco a Linux en los más de 15 años que llevo usándolo. De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, porque es algo que no me entra en la cabeza. Muy errónea tiene que ser la vaga idea que tengo de núcleo para que eso sea posible. El tema de los escritorios, etc. es otro cantar muy distinto. (...) Pues aparentemente en su ciclo de vida/desarrollo. Conforme iba leyendo este hilo¹ (al que apuntaban en la lista de correo debian-vote) se me iban quedando los ojos como platos y me repetía continuamente que lo que estaba leyendo no podía ser verdad. Imponer un sistema de inicio y gestión de procesos que no sabes si va a funcionar con un kernel de hace 3 años (!) no es sólo una cagada sino una auténtica chapuza. ¹http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.11.11.14.59...@gmail.com
Re: remover pam
El Mon, 10 Nov 2014 13:46:54 -0430, Edward Villarroel (EDD) escribió: buenas tardes los molesto en este hilo ahora con la intención de saber quien a removido pam de sus sistemas ya que como bueno curioso instale pam para hacer unas pruebas pero ahora no puedo crear usuarios nuevos ni cambiar el password de los usuarios locales dado que kerberos no me deja creo que por que no me se una password que me pide Kerberos es una mala bestia, los errores que dé y cuándo te aparecen son importantes. Lo que puede haber pasado es que al instalar pam se haya configurado el sistema para usarlo como sistema de autentificación predeterminado en lugar de kerberos. entonces necesito deshacerme de todo lo que instales de pam ya que no pertenezco a ningún dominio es una pc personal... Podrás consultar los paquetes que se instalaron bien desde el registro de apt o aptitude (en /var/log/*) o bien con dkpg -l | grep -i pam. 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.11.11.15.11...@gmail.com
Re: DEBIAN SE CUELGAN TODOS LOS ESCRITORIOS
El Mon, 10 Nov 2014 13:48:16 -0430, Juan Lavieri escribió: El 10 de noviembre de 2014, 13:29, Camaleón noela...@gmail.com escribió: (...) Entonces debe tratarse de este bug: gnome-do: desktop freezes when gnome-do is launched https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768911 Creo haber leído que se le producía el arror también con kde. Este bug no pareciera aplicar. (...) ¿Por qué? Nada impide a gnome-do iniciarse en KDE o cualquier otro entorno. Cierto, pero me refiero al hecho de que no hay nada reportado con usuarios de kde. Quizá porque no es habitual tener gnome, kde, xfce y lxde todos instalados en el mismo sistema :-) Por supuesto no es descartable, pero mi poca experiecia me indica es que si nadie mas está reportando nada parecido (en el caso de Edward por supuesto), lo lógico es suponer que es un problema local, por lo que debería realizar las pruebas que se le indicaron. En el bug indican que también afecta a otros entornos (XFCE y Cinnamon). Ponerse a instalar y desinstalar cosas, sin saber exactamente cuales, no parece muy lógico. Demasiado tarde, ya eliminó medio gnome y volvió a instarlo para después identificar el paquete culpable (el docker gnome-do) de ahí que concuerde con lo experimentado por los distintos informes del bug. 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.11.11.15.15...@gmail.com
Re: remover pam
El 11 de noviembre de 2014, 12:11, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 13:46:54 -0430, Edward Villarroel (EDD) escribió: buenas tardes los molesto en este hilo ahora con la intención de saber quien a removido pam de sus sistemas ya que como bueno curioso instale pam para hacer unas pruebas pero ahora no puedo crear usuarios nuevos ni cambiar el password de los usuarios locales dado que kerberos no me deja creo que por que no me se una password que me pide Kerberos es una mala bestia, los errores que dé y cuándo te aparecen son importantes. Lo que puede haber pasado es que al instalar pam se haya configurado el sistema para usarlo como sistema de autentificación predeterminado en lugar de kerberos. entonces necesito deshacerme de todo lo que instales de pam ya que no pertenezco a ningún dominio es una pc personal... Podrás consultar los paquetes que se instalaron bien desde el registro de apt o aptitude (en /var/log/*) o bien con dkpg -l | grep -i pam. 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.11.11.15.11...@gmail.com Pam es la instacion por default de seguridad de acceso cualquier otra cosa que instales ldap mysql kerberos etc es un backend de pan lo que vos cambiaste es la configuracionde pam en /etc/ tenes los archivos deconfiguracion de pam revisalos para ver que cambio -- MrIX Linux user number 412793. http://counter.li.org/ las grandes obras, las sueñan los santos locos, las realizan los luchadores natos, las aprovechan los felices cuerdo, y las critican los inútiles crónicos,
Problemas con velocidad de disco
Hola, Instale hace unos días un nuevo disco en mi server y empecé a notar que tenia ciertos cuellos de botellas en las VM. Para mi descontento verifique el mismo tiene una velocidad lectura/escritura de 1gb y no de 6gb. Ahora el tema es el siguiente, hice una serie de pruebas para verificar esto disco: http://www.seagate.com/www-content/product-content/constellation-fam/constellation/constellation-2/es-la/docs/constellation2-fips-data-sheet-ds1719-4-1207la.pdf *-disk:1 UNCLAIMED description: ATA Disk product: ST91000640NS vendor: Seagate physical id: 0.0.0 bus info: scsi@0:0.0.0 version: BE29 serial: 9XG5NRG8 capacity: 931GiB (1TB) capabilities: 15000rpm configuration: ansiversion=6 dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync 128+0 registros leídos 128+0 registros escritos 134217728 bytes (134 MB) copiados, 1,2715 s, 106 MB/s hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 24138 MB in 2.00 seconds = 12084.31 MB/sec Timing buffered disk reads: 300 MB in 3.00 seconds = 99.89 MB/sec hdparm -Tt --direct /dev/sda /dev/sda: Timing O_DIRECT cached reads: 120 MB in 2.01 seconds = 59.84 MB/sec Timing O_DIRECT disk reads: 308 MB in 3.00 seconds = 102.54 MB/sec Alguien tiene alguna idea...? -- Marcos Germán Capelari Teléfono: (+54) 0351 - 4281906 Móvil: (+54) 0351 - 152505843 Córdoba - Argentina Mail/Msn: marcoscapel...@gmail.com
Re: Partición pierde UUID
El Tue, 11 Nov 2014 09:44:37 +0100, ZorroPlateado escribió: El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: (...) Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch- upgrading.en.html#boot-timing Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… Bien, pero no te fíes de una única herramienta. Si no devuelve nada puede ser por un error en la aplicación/biblioteca o que el caché desde el que hace la lectura esté vacío (con blkid -p /dev/sdc1 evitas esto último). con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Vale, aceptamos pulpo. No hay UUID, se ha ido o simplemente no existe. Puedes: 1/ Asignarle uno nuevo o el mismo que tenía 2/ Usar cualquier otro identificador Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. Pues sigo sin ver el motivo de por qué no puedes usar el mismo ni la relación de la edad del disco con que no haya UUID. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. Hay controladoras/drivers RAID que sí admiten los comandos smart, tienes una lista en su web: Checking disks behind RAID controllers http://www.smartmontools.org/wiki/Supported_RAID-Controllers 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.11.11.15.30...@gmail.com
Re: Partición pierde UUID
El mar, 11-11-2014 a las 09:44 +0100, ZorroPlateado escribió: El 10/11/2014, a las 15:38, Camaleón noela...@gmail.com escribió: El Mon, 10 Nov 2014 10:42:30 +0100, ZorroPlateado escribió: El 7/11/2014, a las 16:28, Camaleón noela...@gmail.com escribió: (...) La partición sigue siendo igualmente /dev/sdc1… por eso no hay problemas y se va a quedar así, pero es una terrible XXX que te deje un sistema de buenas a primeras sin arrancar por la perdida del UUID. (...) Pues entonces no entiendo qué es lo que te ha pasado. Si no existe el identificador UUID en alguna partición, ni el kernel ni GRUB2 te van a impedir usar cualquier otro identificador para iniciar el sistema. Creo que haberme explicado bien.. La partición boot está identificada por el UUID, así lleva muchos años. Ahora se pierde el UUID de dicha partición y tras el arranque del kernel y llega el momento de montaje del resto de particiones como la boot pues va a fallar. ¿Cómo que se pierde el UUID? Es que si no nos dices el resultado del comando que te puse no queda nada claro lo que dices ni a lo que te refieres. Pero aún así, aunque el identificador uuid de la partición de arranque esté en blanco o no exista puedes usar el identificador que prefieras, eso es indiferente. De modo que la única salida es especificar en el fstab la identificación por path y ya que el problema de volver a asignar el mismo UUID a dicha partición no corrige el asunto no puedo hacer nada más. Por ejemplo, o puedes usar ID o label. Lo que tampoco me termina de quedar claro es por qué asignando el uuid a la partición de arranque (el mismo u otro) dices que no corrige el problema. Ahora estos sintomas de disco solo me pueden avisar de que los 10 años ya pesan y que me prepare para un fallo general. Pues no sabría decirte, me parece un diagnóstico arriesgado. El estado de un disco duro lo puedes medio adivinar con la herramienta smart pero el hecho de que pierda el identificador no podría achacarlo exclusivamente a un fallo mecánico del disco duro ya que puede haber otras causas que lo generen (p. ej., el kernel con udev va demasiado rápido y no detecta el identificador de la partición¹). ¹https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing 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.11.10.14.38...@gmail.com Es muy fácil o llevo diciendo desde el principio , el comando blkid /dev/sdc1 no devuelve nada de nada, ni error ni nada… con tune2fs -U uuid y un posterior blkid seguimos sin obtener el identificador uuid. Efectivamente el UUID ahora mismo no es un método que pueda seguir usando para identificar la partición boot, y el porqué lo desconozco excepto que el disco tras 10 años está empezando a decir basta. El comando smart está bien pero cuando tienes una controladora RAID hardware con discos SCSI como que no, lo que hay que usar es el testing propio de la controladora o vía software si es que lo hay. probablemente haya algun sistema de encriptación de datos instalado, a mí me pasó algo parecido una vez, los dispositivos en vez de aparecerme como sda1, me aparecían como /dev/UIDcon u número largísimo cuando hacía fdisk -l Haz esto a ver fdisk -l -- 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/1415720882.4748.2.ca...@debian.inor.sld.cu
Re: [OT] ¿Es esto un bug de libxslt?
El Mon, 10 Nov 2014 19:36:22 +0100, José Miguel (sio2) escribió: Hola, listeros: Súper-OT pero me encanta XSLT :-P (...) En cambio, esto no funciona: xsl:number count=/fonoteca/disco[@tipo=current()/@tipo] / La salida que se me muestra es la misma que si hubiera escrito: xsl:number count=/fonoteca/disco[@tipo=./@tipo] / o sea, que me cuenta todos los discos. Si he entendido bien, current() se refiere siempre al nodo que está procesando el XSLT y no al nodo de referencia en la expresión XPath. (...) Tomemos lo que dice la normativa (v.2): http://www.w3.org/TR/xslt20/#current-function Creo (creo ojo, porque tengo el lenguaje bien oxidado) que lo que te falla es efectivamente el contexto el que estás procesando la regla y el nivel al que están los dos atributos que usas como filtro de conteo. Es decir, estás usando el mismo valor del atributo (tipo) en el mismo nivel de ahí que el resultado de las dos expresiones sea idéntico. Fíjate en el ejemplo de la documentación: xsl:apply-templates select=//glossary/entry[@name=current()/@ref]/ ^ @name ! @ref (distintos atributos) Y tu expresión: xsl:number count=/fonoteca/disco[@tipo=current()/@tipo] / ^ ^ @tipo = @tipo (mismo atributo) 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.11.11.16.05...@gmail.com
Re: OT: Preguntas de novatos en la lista
El Mon, 10 Nov 2014 15:14:41 -0300, Fabián Bonetti escribió: On Mon, 10 Nov 2014 18:03:45 + (UTC) Camaleón noela...@gmail.com wrote: Todo lo contrario, yo diría que una sesión de IRC por su propia naturaleza es para los más avezados. Una sesión de webchat es a un click. Primero tienes que buscar una web de acceso para IRC. Un click es para principiantes. Registrarse y saber que es un captcha es algo para usuarios medios. https://webchat.freenode.net/ Suponiendo que hayas llegado aquí tienes que saber qué canal poner. Y muchos no saben qué es eso de un canal. No muchos tienen email. Mucho más probable que tengan e-mail que acceso a Internet. Sabiendo eso, no hay cosa mas rápida que eso... un click al webchat. Yo lo encuentro caótico. No sé qué pensarán los novatos pero para mí es un auténtico follón (no sabes quién te responde ni a qué, va todo muy rápido). 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.11.11.16.23...@gmail.com
Re: Problemas con velocidad de disco
El Tue, 11 Nov 2014 12:30:33 -0300, Marcos Germán Capelari escribió: Instale hace unos días un nuevo disco en mi server y empecé a notar que tenia ciertos cuellos de botellas en las VM. ¿Qué tipo de virtualización usas? Para mi descontento verifique el mismo tiene una velocidad lectura /escritura de 1gb y no de 6gb. Querrás decir de 100 MB/s y no de 600 MB/s. Ahora el tema es el siguiente, hice una serie de pruebas para verificar esto disco: http://www.seagate.com/www-content/product-content/constellation-fam/ constellation/constellation-2/es-la/docs/constellation2-fips-data-sheet- ds1719-4-1207la.pdf *-disk:1 UNCLAIMED description: ATA Disk product: ST91000640NS vendor: Seagate physical id: 0.0.0 bus info: scsi@0:0.0.0 version: BE29 serial: 9XG5NRG8 capacity: 931GiB (1TB) capabilities: 15000rpm configuration: ansiversion=6 El modelo que indicas (ST91000640NS) tiene una velocidad de rotación de 7200 rpm no de 15000 rpm ¿es correcto? dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync 128+0 registros leídos 128+0 registros escritos 134217728 bytes (134 MB) copiados, 1,2715 s, 106 MB/s hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 24138 MB in 2.00 seconds = 12084.31 MB/sec Timing buffered disk reads: 300 MB in 3.00 seconds = 99.89 MB/sec hdparm -Tt --direct /dev/sda /dev/sda: Timing O_DIRECT cached reads: 120 MB in 2.01 seconds = 59.84 MB/sec Timing O_DIRECT disk reads: 308 MB in 3.00 seconds = 102.54 MB/sec Alguien tiene alguna idea...? Mira a ver si el kernel detecta la velocidad correctamente (dmesg | grep - i sata) pero en principio no me parece un resultado tan malo. 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.11.11.17.00...@gmail.com
Re: OT: Hay futuro más allá de Jessie
On Tue, Nov 11, 2014 at 02:59:51PM +, Camaleón wrote: Conforme iba leyendo este hilo¹ (al que apuntaban en la lista de correo debian-vote) se me iban quedando los ojos como platos y me repetía continuamente que lo que estaba leyendo no podía ser verdad. Imponer un sistema de inicio y gestión de procesos que no sabes si va a funcionar con un kernel de hace 3 años (!) no es sólo una cagada sino una auténtica chapuza. ¹http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html No veo el problema por ningún lado. El paquete systemd de Debian 8 funcionará bien con el núcleo de Debian 8. El paquete systemd de Debian 9 funcionará bien con el núcleo de Debian 9. El paquete systemd de Debian 10 funcionará bien con el núcleo de Debian 10. etcétera Si para algo valen las distribuciones es para que el usuario final no tenga que preocuparse de este tipo de dependencias. -- 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/2014171435.ga7...@cantor.unex.es
Re: [OT] ¿Es esto un bug de libxslt?
El Tue, 11 de Nov de 2014, a las 04:05:27PM +, Camaleón dijo: Tomemos lo que dice la normativa (v.2): En realidad uso XSLT 1.0, porque libxslt no da para más. http://www.w3.org/TR/xslt20/#current-function Creo (creo ojo, porque tengo el lenguaje bien oxidado) que lo que te falla es efectivamente el contexto el que estás procesando la regla y el nivel al que están los dos atributos que usas como filtro de conteo. Es decir, estás usando el mismo valor del atributo (tipo) en el mismo nivel de ahí que el resultado de las dos expresiones sea idéntico. Fíjate en el ejemplo de la documentación: xsl:apply-templates select=//glossary/entry[@name=current()/@ref]/ ^ @name ! @ref (distintos atributos) Y tu expresión: xsl:number count=/fonoteca/disco[@tipo=current()/@tipo] / @tipo = @tipo (mismo atributo) No veo en qué afecta que esos atributos tengan el mismo nombre (tipo). En la normativa sólo pone que current() hace referencia al nodo que está procesando el procesador XSLT en el momento en que se evalúa la expresión XPath. Nada más. De cómo se llamen o se dejen de llamar atributos que pertenecen a ese nodo, no dice nada. De hecho la misma expresión que me falla en xsl:number me funciona en xsl:if y en xsl:apply-templates. Ahora bien, leyendo ahí mismo veo lo siguiente: If the current function is used within a pattern, its value is the node that is being matched against the pattern. Pero no entiendo muy bien el alcance de esta afirmación y si es la culpable de que con el count de number no funcione y con el select de xsl:apply-templates o el test de xsl:if, sí lo haga. En la especificación que debería estar leyendo (1.0) se dice al respecto: It is an error to use the current function in a pattern. Me autocorrijo. Mirando las deficiones de los elementos xsl:if, xsl:apply-templates y xsl:number veo que se definen: * El test de xsl:if como boolean-expresion. * El select de xsl:apply-templates como node-set-expression. * El count de xsl:number como pattern. Así que esa es la causa. Sin embargo, no tengo muy claro por qué unos atributos son pattern y otros no: no debe ser algo caprichoso. Saludos, Saludos y gracias. -- Quiere, aborrece, trata bien, maltrata, y es la mujer, al fin, como sangría, que a veces da salud y a veces mata. --- Lope de Vega --- -- 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/2014173604.ga2...@cubo.casa
Re: OT: Hay futuro más allá de Jessie
El martes, 11 nov 2014 a las 10:25 horas (UTC+1), Santiago Vila escribió: On Tue, Nov 11, 2014 at 09:12:09AM +0100, Manolo Díaz wrote: De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, [...] Linux no depende de systemd. La dependencia es al revés: systemd utiliza cgroups, que es una característica de Linux. Por este motivo systemd no es fácilmente portable a otros núcleos. Sí, lo sé. Pero leyendo el hilo me da la impresión de que algunas personas defienden que Linux depende de systemd. O tal vez que el desarrollo del núcleo Linux está influido por las exigencias de los desarrolladores de systemd. La respuesta de Camaleón parece ir por este último camino. -- 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/2014185542.60c43...@gmail.com
Re: OT: Hay futuro más allá de Jessie
El martes, 11 nov 2014 a las 15:59 horas (UTC+1), Camaleón escribió: El Tue, 11 Nov 2014 09:12:09 +0100, Manolo Díaz escribió: El martes, 11 nov 2014 a las 08:37 horas (UTC+1), C. L. Martinez escribió: (...) Lo del systemd con el kernel no es un adorno, es la mayor cagada que le conozco a Linux en los más de 15 años que llevo usándolo. De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, porque es algo que no me entra en la cabeza. Muy errónea tiene que ser la vaga idea que tengo de núcleo para que eso sea posible. El tema de los escritorios, etc. es otro cantar muy distinto. (...) Pues aparentemente en su ciclo de vida/desarrollo. Conforme iba leyendo este hilo¹ (al que apuntaban en la lista de correo debian-vote) se me iban quedando los ojos como platos y me repetía continuamente que lo que estaba leyendo no podía ser verdad. Si mi pobre inglés no me la está jugando, systemd va a acompasar su ciclo de desarrollo al de Linux. No veo problema en ello para los que prescindimos de systemd. También avisa que udev va a dejar de ser útil para los sistemas que no usan systemd tan pronto como kdbus esté disponible. Eso ya es más peliagudo, pero sigue sin ser problema del núcleo. Fuerza a las distribuciones a pasar a systemd como único sistema de inicio o a usar una bifurcación de udev. Mucho me sorprendería que no surja una. En cualquier caso Linux te va a seguir siendo útil. Imponer un sistema de inicio y gestión de procesos que no sabes si va a funcionar con un kernel de hace 3 años (!) no es sólo una cagada sino una auténtica chapuza. ¹http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html 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/2014190708.5de68...@gmail.com
Re: Problemas con libaudio2_1.9.4-1+b1_amd64.deb
El 10/11/14 a las 21:24, Manolo Díaz escribió: El lunes, 10 nov 2014 a las 21:12 horas (UTC+1), Eduardo Rios escribió: El 10/11/14 a las 12:42, Debian GMail escribió: Tener cuidado al actualizar Jessie (testing) amd64. Ya me pasó a mí. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768651 JAP Yo actualicé este paquete (y otros muchos) y no me dio error alguno (o no me di cuenta) ¿Como puedo saber si está instalado correctamente? Gracias Una forma es con dpkg -l libaudio2. Si la primera columna es ii (sin comillas), está correctamente instalado. La cabecera de la salida es autoexplicativa. Saludos. Gracias. Pues si, parece que está bien instalado :) root@debian:/home/edurios# dpkg -l libaudio2 Deseado=desconocido(U)/Instalar/eliminaR/Purgar/retener(H) | Estado=No/Inst/ficheros-Conf/desempaqUetado/medio-conF/medio-inst(H)/espera-disparo(W)/pendienTe-disparo |/ Err?=(ninguno)/requiere-Reinst (Estado,Err: mayúsc.=malo) ||/ Nombre Versión Arquitectura Descripción +++-==---= ii libaudio2:amd6 1.9.4-1+b1 amd64Network Audio System - shared lib root@debian:/home/edurios# -- 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/m3tjcp$q7b$1...@ger.gmane.org
Re: Problemas con libaudio2_1.9.4-1+b1_amd64.deb
El 11/11/14 a las 09:59, Luis Felipe Tabera Alonso escribió: El bug solo surge si tienes instalado tanto la versión de 64 como 32 bits ya que hay ficheros distintos en común entre los dos paquetes que no están bien manejados. Si no te dio error no hay razones para suponer que está mal instalado. Luis Gracias Luis. Vale, entonces es por eso por lo que no tuve problemas, sólo tengo instalada la versión 64 bits. -- 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/m3tjfv$q7b$2...@ger.gmane.org
Re: OT: Hay futuro más allá de Jessie
El Tue, 11 Nov 2014 19:07:08 +0100, Manolo Díaz escribió: El martes, 11 nov 2014 a las 15:59 horas (UTC+1), Camaleón escribió: El Tue, 11 Nov 2014 09:12:09 +0100, Manolo Díaz escribió: El martes, 11 nov 2014 a las 08:37 horas (UTC+1), C. L. Martinez escribió: (...) Lo del systemd con el kernel no es un adorno, es la mayor cagada que le conozco a Linux en los más de 15 años que llevo usándolo. De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, porque es algo que no me entra en la cabeza. Muy errónea tiene que ser la vaga idea que tengo de núcleo para que eso sea posible. El tema de los escritorios, etc. es otro cantar muy distinto. (...) Pues aparentemente en su ciclo de vida/desarrollo. Conforme iba leyendo este hilo¹ (al que apuntaban en la lista de correo debian-vote) se me iban quedando los ojos como platos y me repetía continuamente que lo que estaba leyendo no podía ser verdad. Si mi pobre inglés no me la está jugando, systemd va a acompasar su ciclo de desarrollo al de Linux. No veo problema en ello para los que prescindimos de systemd. Menudo eufemismo. No, no dice eso. Dice que si por el motivo que sea necesitas usar un kernel de hace más de 3 años con cualquier distribución actual que *necesita* systemd, puede que funcione o puede que no. Puede que cargue o puede que no. Puede que inicie o puede que no. Puede que se cuelgue o puede que no. Que el único escenario *soportado* es un kernel que vaya a la par de systemd. Y lo sueltan así y se quedan tan panchos. También avisa que udev va a dejar de ser útil para los sistemas que no usan systemd tan pronto como kdbus esté disponible. Eso ya es más peliagudo, pero sigue sin ser problema del núcleo. Fuerza a las distribuciones a pasar a systemd como único sistema de inicio o a usar una bifurcación de udev. Mucho me sorprendería que no surja una. Me parece que en Gentoo ya llevan cocinado algo. Pero muy diferente es que se trate de una funcionalidad que sea o deje ser útil a otra que te impida iniciar el sistema o que haga que se vuelva inestable. Es que no se trata de una funcionalidad cualquiera sino de un servicio vital para el funcionamiento del equipo. En cualquier caso Linux te va a seguir siendo útil. Sinceramente, cuando leo a los súper-mandamases escribir esas cosas me entran escalofríos. Esa ligereza y condescendencia con la que tratan asuntos tan serios y la forma de responder a quienes expresan su preocupación por los cambios que les afectan directamente, asusta y me hace pensar hasta cuándo me va seguir resultando de utilidad porque la dinámica que llevan me hace sentir que estoy completamente en fuera de juego :-/ 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.11.11.18.25...@gmail.com
Re: Problemas con velocidad de disco
Con fecha Martes, 11 de Noviembre de 2014, 12:30:33 p.m., Marcos escribió: Instale hace unos días un nuevo disco en mi server y empecé a notar que tenia ciertos cuellos de botellas en las VM. Para mi descontento verifique el mismo tiene una velocidad lectura/escritura de 1gb y no de 6gb. Ahora el tema es el siguiente, hice una serie de pruebas para verificar esto disco: http://www.seagate.com/www-content/product-content/constellation-fam/constellation/constellation-2/es-la/docs/constellation2-fips-data-sheet-ds1719-4-1207la.pdf *-disk:1 UNCLAIMED description: ATA Disk product: ST91000640NS vendor: Seagate capabilities: 15000rpm 134217728 bytes (134 MB) copiados, 1,2715 s, 106 MB/s Mira... yo creo que una velocidad de 106 MBytes/seg. está más que bien teniendo en cuenta que según lo que se lee el el manual del disco cuyo enlace nos proporcionaste dice con claridad: Máx. velocidad de transferencia continua (MB/s) 115 O sea... que la transferencia de 106 MBytes/seg. está muy cerca de la máxima declarada en la ficha técnica del disco por lo que creo que mucho más no se le deberá pedir a ese disco. RECUERDA que los mencionados y publicitados 6 Gbit/seg. reflejan SOLAMENTE la velocidad de acceso a la interfaz pero NO es, de ningún modo, la velocidad de transferencia continua. O sea... cuando el disco recibe hasta 64 MB (que es el tamaño del cache del disco) allí sí puede tener esa velocidad de 6Gb/s de allí en más... sólo hasta su máxima 115 MB/s que por otra parte... no se alcanza casi nunca. -- Saludos, Eduardomailto:egis_e...@yahoo.com.ar -- 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/455792888.2014153...@yahoo.com.ar
Re: OT: Hay futuro más allá de Jessie
El martes, 11 nov 2014 a las 19:25 horas (UTC+1), Camaleón escribió: El Tue, 11 Nov 2014 19:07:08 +0100, Manolo Díaz escribió: El martes, 11 nov 2014 a las 15:59 horas (UTC+1), Camaleón escribió: El Tue, 11 Nov 2014 09:12:09 +0100, Manolo Díaz escribió: El martes, 11 nov 2014 a las 08:37 horas (UTC+1), C. L. Martinez escribió: (...) Lo del systemd con el kernel no es un adorno, es la mayor cagada que le conozco a Linux en los más de 15 años que llevo usándolo. De verdad, a mí me gustaría saber en qué depende el núcleo Linux de systemd, porque es algo que no me entra en la cabeza. Muy errónea tiene que ser la vaga idea que tengo de núcleo para que eso sea posible. El tema de los escritorios, etc. es otro cantar muy distinto. (...) Pues aparentemente en su ciclo de vida/desarrollo. Conforme iba leyendo este hilo¹ (al que apuntaban en la lista de correo debian-vote) se me iban quedando los ojos como platos y me repetía continuamente que lo que estaba leyendo no podía ser verdad. Si mi pobre inglés no me la está jugando, systemd va a acompasar su ciclo de desarrollo al de Linux. No veo problema en ello para los que prescindimos de systemd. Menudo eufemismo. No, no dice eso. Dice que si por el motivo que sea necesitas usar un kernel de hace más de 3 años con cualquier distribución actual que *necesita* systemd, puede que funcione o puede que no. Puede que cargue o puede que no. Puede que inicie o puede que no. Puede que se cuelgue o puede que no. Que el único escenario *soportado* es un kernel que vaya a la par de systemd. Y lo sueltan así y se quedan tan panchos. Querrás decir que tú no haces hincapié en ello. En lo que te preocupa: que usas systemd, la distro te proveerá un núcleo compatible; que no, no te afecta. El único problema que puede plantearse es que alguien use systemd y quiera/necesite un núcleo más antiguo que el que provee la distro. En algún punto hay que limitar lo que se ofrece: el tiempo y las ganas de los desarrolladores y/o mantenedores no son infinitos. También avisa que udev va a dejar de ser útil para los sistemas que no usan systemd tan pronto como kdbus esté disponible. Eso ya es más peliagudo, pero sigue sin ser problema del núcleo. Fuerza a las distribuciones a pasar a systemd como único sistema de inicio o a usar una bifurcación de udev. Mucho me sorprendería que no surja una. Me parece que en Gentoo ya llevan cocinado algo. Pero muy diferente es que se trate de una funcionalidad que sea o deje ser útil a otra que te impida iniciar el sistema o que haga que se vuelva inestable. Es que no se trata de una funcionalidad cualquiera sino de un servicio vital para el funcionamiento del equipo. De acuerdo, udev no es una pieza de programación cualquiera, aunque creo que tampoco es completamente imprescindible. En cualquier caso Linux te va a seguir siendo útil. Sinceramente, cuando leo a los súper-mandamases escribir esas cosas me entran escalofríos. Esa ligereza y condescendencia con la que tratan asuntos tan serios y la forma de responder a quienes expresan su preocupación por los cambios que les afectan directamente, asusta y me hace pensar hasta cuándo me va seguir resultando de utilidad porque la dinámica que llevan me hace sentir que estoy completamente en fuera de juego :-/ Vale, pero una cosa que tengo clara es que no tengo derecho a decirle cómo tiene que enfocar el proyecto. A los que únicamente somos usuarios solo nos asiste los derechos de tomarlo o dejarlo y hacer sugerencias amablemente expresadas. Y no es que me dé igual lo que está ocurriendo. 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/2014202216.6ec34...@gmail.com
Re: OT: Hay futuro más allá de Jessie
On Tue, Nov 11, 2014 at 06:55:42PM +0100, Manolo Díaz wrote: [...] Pero leyendo el hilo me da la impresión de que algunas personas defienden que Linux depende de systemd. O tal vez que el desarrollo del núcleo Linux está influido por las exigencias de los desarrolladores de systemd. [...] Yo no veo nada de eso. El hilo trata de eliminar del código de udev la parte que se encarga de cargar el firmware, porque eso ya lo hace el núcleo y es código innecesario en udev. El único problema es que hay que usar un núcleo reciente porque eso no siempre lo hizo el núcleo. En el hilo, Greg Kroah-Hartman pregunta repetidas veces, y con razón, quién en su sano juicio actualizaría udev pero *no* el núcleo. Es decir, lo que hay aquí no es una dependencia de Linux en systemd, sino una dependencia de udev en una versión suficientemente moderna del núcleo (porque un udev demasiado moderno con un núcleo demasiado antiguo podría suponer que no hay nada en el sistema encargado de cargar el firmware). Este tipo de dependencias (cosas que dependen de versiones recientes de las cosas que tienen debajo) son de lo más normal y suceden todos los días, y no es para rasgarse las vestiduras. Por ejemplo, cualquier paquete que se compila en jessie acaba teniendo Depends en las bibliotecas de jessie y difícilmente se podrá usar en wheezy tal cual. -- 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/2014191534.ga8...@cantor.unex.es
Re: OT: Hay futuro más allá de Jessie
El martes, 11 nov 2014 a las 20:15 horas (UTC+1), Santiago Vila escribió: On Tue, Nov 11, 2014 at 06:55:42PM +0100, Manolo Díaz wrote: [...] Pero leyendo el hilo me da la impresión de que algunas personas defienden que Linux depende de systemd. O tal vez que el desarrollo del núcleo Linux está influido por las exigencias de los desarrolladores de systemd. [...] Yo no veo nada de eso. El hilo trata de eliminar del código de udev la parte que se encarga de cargar el firmware, porque eso ya lo hace el núcleo y es código innecesario en udev. El único problema es que hay que usar un núcleo reciente porque eso no siempre lo hizo el núcleo. No me refería al hilo de Lennart Poettering cuando escribí lo que citas; me refería a este hilo, al nuestro. En el hilo, Greg Kroah-Hartman pregunta repetidas veces, y con razón, quién en su sano juicio actualizaría udev pero *no* el núcleo. Es decir, lo que hay aquí no es una dependencia de Linux en systemd, sino una dependencia de udev en una versión suficientemente moderna del núcleo (porque un udev demasiado moderno con un núcleo demasiado antiguo podría suponer que no hay nada en el sistema encargado de cargar el firmware). Este tipo de dependencias (cosas que dependen de versiones recientes de las cosas que tienen debajo) son de lo más normal y suceden todos los días, y no es para rasgarse las vestiduras. Por ejemplo, cualquier paquete que se compila en jessie acaba teniendo Depends en las bibliotecas de jessie y difícilmente se podrá usar en wheezy tal cual. Nada que objetar a todo lo anterior. 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/2014210500.62a37...@gmail.com
Re: Problemas con velocidad de disco
Hola, Estaba leyendo eso mismo y justamente me quedaba esa duda. Ahora lo siguiente, existe alguna manera de mejorar la velocidad de lectura/escritura? poner otro disco y hacer data striping (tengo 3 bahías libres)? Como aclaración tengo otro disco de igual características en un raid 1 por red en una placa de giga. -- Marcos Germán Capelari Teléfono: (+54) 0351 - 4281906 Móvil: (+54) 0351 - 152505843 Córdoba - Argentina Mail/Msn: marcoscapel...@gmail.com
Re: Problemas con velocidad de disco
El día 11 de noviembre de 2014, 17:22, Marcos Germán Capelari marcoscapel...@gmail.com escribió: Hola, Estaba leyendo eso mismo y justamente me quedaba esa duda. Ahora lo siguiente, existe alguna manera de mejorar la velocidad de lectura/escritura? poner otro disco y hacer data striping (tengo 3 bahías libres)? Realmente no, es algo físico.. Con raid, la mejora en lectura va en detrimento de la velocidad de escritura, y viceversa. No podes mejorar las dos a la vez, tal vez con mas cache de memoria, pero eso depende de la aplicació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/cadqxbrsh6omffv9_t5aju+wbkzwembcqueqr3xkpxkp86t5...@mail.gmail.com
Remover espacio en log remoto enviado a rsyslog
Hola buenas, estoy enviando logs de servidores web a un servidor de logs centralizados configurado con rsyslog. He conseguido remover el timestamp que rsyslog mete a los logs cuando los recibe, pero aún así me deja un espacio. Con esta configuración deshabilito el timestamp: $template MsgFormat,%msg%\n local1.*/var/log/remote/access.log;MsgFormat Pero aún así, me deja un espacio delante de las lineas de los logs recibidos de esta forma: www.example.org 443 82.82.82.82 .. Necesito escapar ese espacio para que programas para analizar logs no fallen o digan que el archivo de log es corrupto. Alguna idea para escaparlo desde rsyslog? Estoy googleando pero no veo nada. Gracias de antemano. Saludos. -- 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/CAJ2aOA_xpVCiXS1orAKCtz3Ou8tkb5iNs7HZO+QToy=_rdu...@mail.gmail.com
(SOLUCIONADO) Re: Remover espacio en log remoto enviado a rsyslog
El día 11 de noviembre de 2014, 22:49, Maykel Franco maykeldeb...@gmail.com escribió: Hola buenas, estoy enviando logs de servidores web a un servidor de logs centralizados configurado con rsyslog. He conseguido remover el timestamp que rsyslog mete a los logs cuando los recibe, pero aún así me deja un espacio. Con esta configuración deshabilito el timestamp: $template MsgFormat,%msg%\n local1.*/var/log/remote/access.log;MsgFormat Pero aún así, me deja un espacio delante de las lineas de los logs recibidos de esta forma: www.example.org 443 82.82.82.82 .. Necesito escapar ese espacio para que programas para analizar logs no fallen o digan que el archivo de log es corrupto. Alguna idea para escaparlo desde rsyslog? Estoy googleando pero no veo nada. Gracias de antemano. Saludos. Me respondo a mi mismo, con este cambio en la configuración he conseguido escapar ese espacio: $template MsgFormat,%msg:2:2048%\n Gracias no obstante. Saludos. -- 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/CAJ2aOA8rLQcfttnStav4zvGZKv=btiutvwgrw5gqpz5auyg...@mail.gmail.com
