[opensuse-es] lvm o particiones extendidas
Hola, tengo un server con un disco de 65 GB, a mi me gusta hacer bastantes particiones para separarlo todo (/, /var, /usr, /tmp, /home, /opt, etc.) y si es posible particiones primarias... pero en el caso de que no.. que recomendais? lvm? crear particiones extendidas? como os las apañais cuando teneis un solo disco y quereis crear mas de 4 particiones? todo esto mirando el rendimiento y la sencillez a la hora de recuperar la información en caso de desastre, etc. gracias -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 20 Apr 2010 16:56:31 +0200, aux escribió:
Hola, tengo un server con un disco de 65 GB, a mi me gusta hacer bastantes particiones para separarlo todo (/, /var, /usr, /tmp, /home, /opt, etc.) y si es posible particiones primarias... pero en el caso de que no.. que recomendais? lvm? crear particiones extendidas? como os las apañais cuando teneis un solo disco y quereis crear mas de 4 particiones? todo esto mirando el rendimiento y la sencillez a la hora de recuperar la información en caso de desastre, etc.
Primarias sólo puedes hacer 3 y luego, una lógica que contenga el resto de particiones extendidas que quieras. Pero con un disco tan pequeño de 65 GiB (¿65 GiB o *650 GiB*?) yo no "partiría" mucho. Tratándose de un servidor te puedes quedar sin espacio fácilmente (y recuerda que ext3 se reserva el 5% del espacio para uso propio). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Martes 20 Abril 2010 17:18:08 Camaleón escribió:
El Tue, 20 Apr 2010 16:56:31 +0200, aux escribió:
Hola, tengo un server con un disco de 65 GB, a mi me gusta hacer bastantes particiones para separarlo todo (/, /var, /usr, /tmp, /home, /opt, etc.) y si es posible particiones primarias... pero en el caso de que no.. que recomendais? lvm? crear particiones extendidas? como os las apañais cuando teneis un solo disco y quereis crear mas de 4 particiones? todo esto mirando el rendimiento y la sencillez a la hora de recuperar la información en caso de desastre, etc.
Primarias sólo puedes hacer 3 y luego, una lógica que contenga el resto de particiones extendidas que quieras.
Pero con un disco tan pequeño de 65 GiB (¿65 GiB o *650 GiB*?) yo no "partiría" mucho. Tratándose de un servidor te puedes quedar sin espacio fácilmente (y recuerda que ext3 se reserva el 5% del espacio para uso propio).
Saludos,
Por espacio no hay problema... esto solo es para el S.O, los datos van en la SAN, pero aun así el s.o me gusta particionarlo bastante -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 20 Apr 2010 17:36:14 +0200, aux escribió:
On Martes 20 Abril 2010 17:18:08 Camaleón escribió:
(...)
Pero con un disco tan pequeño de 65 GiB (¿65 GiB o *650 GiB*?) yo no "partiría" mucho. Tratándose de un servidor te puedes quedar sin espacio fácilmente (y recuerda que ext3 se reserva el 5% del espacio para uso propio).
Por espacio no hay problema... esto solo es para el S.O, los datos van en la SAN, pero aun así el s.o me gusta particionarlo bastante
Es que dependiendo del uso que le des al equipo, las particiones se te pueden llenar en seguida (/var por ejemplo). Yo tiraría por particiones lógicas/extendidas, son más sencillas de gestionar. El LVM no lo he trabajado pero sé que añade una capa de complejidad que podría ser problemática en algunos casos. Salvo que fuera estrictamente necesario (porque tienes pensando expandir volúmenes o redimensionar espacio de almacenamiento) lo dejaría de lado. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Martes 20 Abril 2010 17:49:20 Camaleón escribió:
El Tue, 20 Apr 2010 17:36:14 +0200, aux escribió:
On Martes 20 Abril 2010 17:18:08 Camaleón escribió:
(...)
Pero con un disco tan pequeño de 65 GiB (¿65 GiB o *650 GiB*?) yo no "partiría" mucho. Tratándose de un servidor te puedes quedar sin espacio fácilmente (y recuerda que ext3 se reserva el 5% del espacio para uso propio).
Por espacio no hay problema... esto solo es para el S.O, los datos van en la SAN, pero aun así el s.o me gusta particionarlo bastante
Es que dependiendo del uso que le des al equipo, las particiones se te pueden llenar en seguida (/var por ejemplo).
Yo tiraría por particiones lógicas/extendidas, son más sencillas de gestionar. El LVM no lo he trabajado pero sé que añade una capa de complejidad que podría ser problemática en algunos casos.
Salvo que fuera estrictamente necesario (porque tienes pensando expandir volúmenes o redimensionar espacio de almacenamiento) lo dejaría de lado.
Saludos,
las particiones extendidas dan mejor rendimiento que con LVM? Sabes si son mas fáciles de recuperar ante algún fallo? -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 20 Apr 2010 19:20:28 +0200, aux escribió:
On Martes 20 Abril 2010 17:49:20 Camaleón escribió:
(...)
Yo tiraría por particiones lógicas/extendidas, son más sencillas de gestionar. El LVM no lo he trabajado pero sé que añade una capa de complejidad que podría ser problemática en algunos casos.
Salvo que fuera estrictamente necesario (porque tienes pensando expandir volúmenes o redimensionar espacio de almacenamiento) lo dejaría de lado.
las particiones extendidas dan mejor rendimiento que con LVM? Sabes si son mas fáciles de recuperar ante algún fallo?
Que yo sepa las particiones extendidas son particiones estándar, igual que las primarias (con algunas limitaciones pero ninguna diferencia en cuanto a rendimiento se refiere). ¿Rendimiento entre particiones primarias/lógicas y uso de LVM? Pues el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que los volúmenes LVM deben procesar más datos (meta- datos) así que deberían ser más lentorros (algo similar al uso de un volumen en raid1, por ejemplo). Pero no creo que nadie use volúmenes LVM para obtener mayor rendimiento -salvo para casos muy concretos- sino por la flexibilidad en el manejo del tamaño de las particiones y la posibilidad de realizar las operaciones de redimensionado "en línea". En cuanto a la recuperación de datos, también el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que al contrario, en caso de corrupción de datos, la recuperación sería más complicada, hay más "capas" a tener en cuenta ("¿qué se ha corrompido, el LVM o el sistema de archivos o se trata de un problema con el disco?"). Bueno, vaaaale, no soy la persona más indicada para comentar sobre el LVM porque no lo he probado :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Tuesday 20 April 2010 19:37 Camaleón wrote
El Tue, 20 Apr 2010 19:20:28 +0200, aux escribió:
On Martes 20 Abril 2010 17:49:20 Camaleón escribió: (...)
Yo tiraría por particiones lógicas/extendidas, son más sencillas de gestionar. El LVM no lo he trabajado pero sé que añade una capa de complejidad que podría ser problemática en algunos casos.
Salvo que fuera estrictamente necesario (porque tienes pensando expandir volúmenes o redimensionar espacio de almacenamiento) lo dejaría de lado.
las particiones extendidas dan mejor rendimiento que con LVM? Sabes si son mas fáciles de recuperar ante algún fallo?
Que yo sepa las particiones extendidas son particiones estándar, igual que las primarias (con algunas limitaciones pero ninguna diferencia en cuanto a rendimiento se refiere).
¿Rendimiento entre particiones primarias/lógicas y uso de LVM? Pues el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que los volúmenes LVM deben procesar más datos (meta- datos) así que deberían ser más lentorros (algo similar al uso de un volumen en raid1, por ejemplo). Pero no creo que nadie use volúmenes LVM para obtener mayor rendimiento -salvo para casos muy concretos- sino por la flexibilidad en el manejo del tamaño de las particiones y la posibilidad de realizar las operaciones de redimensionado "en línea".
Si haces un "stripe" de LVM y usas un sistema de ficheros paralelizado (que no paralelo), el rendimiento es mayor ya que los discos leen y escriben en paralelo (todos a la vez). Esto sería similar a un RAID 0. Digo similar porque RAID es una cosa y voúmenes es otra ;) En cambio un apartición de un disco es más lenta porque: - comparte acceso al mismo disco junto con otras particiones, es decir, si estás leyendo y/o escribiendo en /dev/sda1, no lo puedes hacer al mismo tiempo en /dev/sda23. - aunque no comparta disco con otras particiones, es decir /dev/sda1 sea el disco entero, la velocidad máxima que vas a obtener es la velocidad máxima del disco. En LVM, si haces un stripe, consigues la suma de las velocidade de los discos (teóricamente, todos sabemos que en la práctica no es lineal 100% ;) Otra cosa, hacer LVM sobre un disco no tiene sentido, LVM es útil si tienes múltiples discos y/o sabes que vas a tener que crecer el sistema de ficheros. Los sistemas de ficheros que crecen son aquellos que guardan los datos de los usuarios: /home, /mnt/samba o como llames a lo que exportas vía SMB/CIFS y/o NFS. /var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio. En el caso d elos usuarios, TAMBIÉN se _DEBERÍA_ (fijaos en el énfasis en debería, todos sabemos que deber = mundo ideal ;) usar archivado y almacenamiento jerárquico (además de backup) así como deduplicación (dedupe). NOTA: Si usas LVM y quieres conseguir buen rendimiento ... usa el disco entero para LVM.
En cuanto a la recuperación de datos, también el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que al contrario, en caso de corrupción de datos, la recuperación sería más complicada, hay más "capas" a tener en cuenta ("¿qué se ha corrompido, el LVM o el sistema de archivos o se trata de un problema con el disco?").
LVM (o cualquier otro gestor de volúmenes) TIENE que ir SIEMPRE sobre un RAID con protección de datos (!= RAID 0) de lo contrario estás pidiendo a gritos que se te pierdan los datos. Un gestor de volúmenes lo único que hace es expandir la capacidad de un disco de forma lógica (por software), pero NO incluye protección de datos (para eso está RAID ;)
Bueno, vaaaale, no soy la persona más indicada para comentar sobre el LVM porque no lo he probado :-P
Como siempre, es útil para lo que es y hay que usarlo correctamente, de lo contrario... bye bye datos :( Pruébalo, es bastante útil. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 21 Apr 2010 08:55:10 +0200, Rafa Grimán escribió:
Hola :)
Ya me estaba preguntando por dónde andabas :-)
On Tuesday 20 April 2010 19:37 Camaleón wrote
¿Rendimiento entre particiones primarias/lógicas y uso de LVM? Pues el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que los volúmenes LVM deben procesar más datos (meta- datos) así que deberían ser más lentorros (algo similar al uso de un volumen en raid1, por ejemplo). Pero no creo que nadie use volúmenes LVM para obtener mayor rendimiento -salvo para casos muy concretos- sino por la flexibilidad en el manejo del tamaño de las particiones y la posibilidad de realizar las operaciones de redimensionado "en línea".
Si haces un "stripe" de LVM y usas un sistema de ficheros paralelizado (que no paralelo), el rendimiento es mayor ya que los discos leen y escriben en paralelo (todos a la vez). Esto sería similar a un RAID 0. Digo similar porque RAID es una cosa y voúmenes es otra ;)
(...)
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Hum... discrepo :-) "/var" lo usan en muchas distribuciones como almacén raíz de documentos del servidor web (p. ej. yo ahora lo tengo en "/var/www", por algo relacionado con el FHS y Apache, aunque en openSUSE lo montan bajo "/ srv/"). También tenemos las colas de los correos y si usas el almacenamiento de Postfix los mensajes se quedan ahí hasta que el usuario se los baja... si es que los baja porque ahora la moda es el imap "y que se apañe el servidor" :-P Además, quienes usamos un servidor de faxes, también tenemos los archivos de hylafax almacenados ahí (/var/spool/hylafax) y al ser archivos PS y TIFF ocupan unos cuantos KiB >:-) stt005:~# du -s -h /var 2,6G /var stt005:~# df -h /dev/sda2 S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sda2 81G 7,0G 74G 9% / Es decir, la tercera parte de uso total de la partición es para "/var". (...) El resto de la "excelente" (boing, boing -> pelota que soy :-P) información que das intuyo que le va a venir de perlas a Aux. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Miércoles 21 Abril 2010 10:43:19 Camaleón escribió:
El Wed, 21 Apr 2010 08:55:10 +0200, Rafa Grimán escribió:
Hola :)
Ya me estaba preguntando por dónde andabas :-)
On Tuesday 20 April 2010 19:37 Camaleón wrote
¿Rendimiento entre particiones primarias/lógicas y uso de LVM? Pues el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que los volúmenes LVM deben procesar más datos (meta- datos) así que deberían ser más lentorros (algo similar al uso de un volumen en raid1, por ejemplo). Pero no creo que nadie use volúmenes LVM para obtener mayor rendimiento -salvo para casos muy concretos- sino por la flexibilidad en el manejo del tamaño de las particiones y la posibilidad de realizar las operaciones de redimensionado "en línea".
Si haces un "stripe" de LVM y usas un sistema de ficheros paralelizado (que no paralelo), el rendimiento es mayor ya que los discos leen y escriben en paralelo (todos a la vez). Esto sería similar a un RAID 0. Digo similar porque RAID es una cosa y voúmenes es otra ;)
(...)
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Hum... discrepo :-)
"/var" lo usan en muchas distribuciones como almacén raíz de documentos del servidor web (p. ej. yo ahora lo tengo en "/var/www", por algo relacionado con el FHS y Apache, aunque en openSUSE lo montan bajo "/ srv/").
También tenemos las colas de los correos y si usas el almacenamiento de Postfix los mensajes se quedan ahí hasta que el usuario se los baja... si es que los baja porque ahora la moda es el imap "y que se apañe el servidor" :-P
Además, quienes usamos un servidor de faxes, también tenemos los archivos de hylafax almacenados ahí (/var/spool/hylafax) y al ser archivos PS y TIFF ocupan unos cuantos KiB >:-)
stt005:~# du -s -h /var 2,6G /var
stt005:~# df -h /dev/sda2 S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sda2 81G 7,0G 74G 9% /
Es decir, la tercera parte de uso total de la partición es para "/var".
(...)
El resto de la "excelente" (boing, boing -> pelota que soy :-P) información que das intuyo que le va a venir de perlas a Aux.
ni que lo digas... ;-) Fantástica explicación, gracias a todos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 21 April 2010 10:43 Camaleón wrote
El Wed, 21 Apr 2010 08:55:10 +0200, Rafa Grimán escribió:
Hola :)
Ya me estaba preguntando por dónde andabas :-)
Un poco de jaleo 0;)
On Tuesday 20 April 2010 19:37 Camaleón wrote
¿Rendimiento entre particiones primarias/lógicas y uso de LVM? Pues el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que los volúmenes LVM deben procesar más datos (meta- datos) así que deberían ser más lentorros (algo similar al uso de un volumen en raid1, por ejemplo). Pero no creo que nadie use volúmenes LVM para obtener mayor rendimiento -salvo para casos muy concretos- sino por la flexibilidad en el manejo del tamaño de las particiones y la posibilidad de realizar las operaciones de redimensionado "en línea".
Si haces un "stripe" de LVM y usas un sistema de ficheros paralelizado (que no paralelo), el rendimiento es mayor ya que los discos leen y escriben en paralelo (todos a la vez). Esto sería similar a un RAID 0. Digo similar porque RAID es una cosa y voúmenes es otra ;)
(...)
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Hum... discrepo :-)
No me lo puedo yo de creer ;)
"/var" lo usan en muchas distribuciones como almacén raíz de documentos del servidor web (p. ej. yo ahora lo tengo en "/var/www", por algo relacionado con el FHS y Apache, aunque en openSUSE lo montan bajo "/ srv/").
También tenemos las colas de los correos y si usas el almacenamiento de Postfix los mensajes se quedan ahí hasta que el usuario se los baja... si es que los baja porque ahora la moda es el imap "y que se apañe el servidor" :-P
Además, quienes usamos un servidor de faxes, también tenemos los archivos de hylafax almacenados ahí (/var/spool/hylafax) y al ser archivos PS y TIFF ocupan unos cuantos KiB >:-)
stt005:~# du -s -h /var 2,6G /var
stt005:~# df -h /dev/sda2 S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sda2 81G 7,0G 74G 9% /
Es decir, la tercera parte de uso total de la partición es para "/var".
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;) Voy a hacer un poco de spam de un partner, pero es sólo para que lo veáis, no porque quiera venderos algo ;) ATEMPO tiene un producto llamado ADA(M) que es un módulo de archivado. Lo que permite es pasar a otro medio todos aquellos ficheros (logs, por ejemplo, proyectos antiguos) y correos antiguos. Generalemente se pasan a cinta, pero pueden pasarse a disco. Al usuario se le instala una interfaz gráfica y el usuario va pasando ficheros y correos antiguos a cinta/disco. Estaréis pensando: "Si lo dejo en manos del usuario ... jamás lo hará, se le olvidará, ...". Por eso existen la sreglas que define el admin ;) Vamos que se puede programar para que cada mes se migren los datos o bien si el fichero es mayor a X MBytes o lo que el admin decida. El producto se integra con el backup también. Herramientas FLOSS no he visto, bueno, he visto archivado de correo: - http://www.mailarchiva.com/ - http://www.archiveopteryx.org/overview - http://www.inovox.de/products/e-mail-archiving/e-mail-archiving - http://www.opsera.com/products/opsmailmanager/omm_overview.dot Pero no todo junto (archivado de correo y ficheros). Archivado de ficheros tienes tar, cpio, dar/kdar, ... pero no es tan "bonito" ni cómodo como para poner a nivel corporativo con su agente en el PC del usuario, ... :( Si hay alguien que maneje MS-Exchange, que me corrija, pero creo que MS- Exchange lo hace internamente, que no hace falta una herramienta externa de archivado. El dedupe también es muy útil porque reduce el espacio ocupado, otra técnica más para reducirlo. Y no nos podemos olvidar de las quotas ;)
El resto de la "excelente" (boing, boing -> pelota que soy :-P) información que das intuyo que le va a venir de perlas a Aux.
<blush> Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.2 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Rafa Grimán wrote:
Hola :)
On Wednesday 21 April 2010 10:43 Camaleón wrote
El Wed, 21 Apr 2010 08:55:10 +0200, Rafa Grimán escribió:
Hola :) Ya me estaba preguntando por dónde andabas :-)
Un poco de jaleo 0;)
On Tuesday 20 April 2010 19:37 Camaleón wrote
¿Rendimiento entre particiones primarias/lógicas y uso de LVM? Pues el sentido común (disclaimer: apreciación totalmente personal y sin fundamento) me dice que los volúmenes LVM deben procesar más datos (meta- datos) así que deberían ser más lentorros (algo similar al uso de un volumen en raid1, por ejemplo). Pero no creo que nadie use volúmenes LVM para obtener mayor rendimiento -salvo para casos muy concretos- sino por la flexibilidad en el manejo del tamaño de las particiones y la posibilidad de realizar las operaciones de redimensionado "en línea". Si haces un "stripe" de LVM y usas un sistema de ficheros paralelizado (que no paralelo), el rendimiento es mayor ya que los discos leen y escriben en paralelo (todos a la vez). Esto sería similar a un RAID 0. Digo similar porque RAID es una cosa y voúmenes es otra ;) (...)
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio. Hum... discrepo :-)
No me lo puedo yo de creer ;)
"/var" lo usan en muchas distribuciones como almacén raíz de documentos del servidor web (p. ej. yo ahora lo tengo en "/var/www", por algo relacionado con el FHS y Apache, aunque en openSUSE lo montan bajo "/ srv/").
También tenemos las colas de los correos y si usas el almacenamiento de Postfix los mensajes se quedan ahí hasta que el usuario se los baja... si es que los baja porque ahora la moda es el imap "y que se apañe el servidor" :-P
Además, quienes usamos un servidor de faxes, también tenemos los archivos de hylafax almacenados ahí (/var/spool/hylafax) y al ser archivos PS y TIFF ocupan unos cuantos KiB >:-)
stt005:~# du -s -h /var 2,6G /var
stt005:~# df -h /dev/sda2 S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sda2 81G 7,0G 74G 9% /
Es decir, la tercera parte de uso total de la partición es para "/var".
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;)
Voy a hacer un poco de spam de un partner, pero es sólo para que lo veáis, no porque quiera venderos algo ;)
ATEMPO tiene un producto llamado ADA(M) que es un módulo de archivado. Lo que permite es pasar a otro medio todos aquellos ficheros (logs, por ejemplo, proyectos antiguos) y correos antiguos. Generalemente se pasan a cinta, pero pueden pasarse a disco. Al usuario se le instala una interfaz gráfica y el usuario va pasando ficheros y correos antiguos a cinta/disco.
Estaréis pensando: "Si lo dejo en manos del usuario ... jamás lo hará, se le olvidará, ...". Por eso existen la sreglas que define el admin ;) Vamos que se puede programar para que cada mes se migren los datos o bien si el fichero es mayor a X MBytes o lo que el admin decida.
El producto se integra con el backup también.
Herramientas FLOSS no he visto, bueno, he visto archivado de correo: - http://www.mailarchiva.com/ - http://www.archiveopteryx.org/overview - http://www.inovox.de/products/e-mail-archiving/e-mail-archiving - http://www.opsera.com/products/opsmailmanager/omm_overview.dot
Pero no todo junto (archivado de correo y ficheros).
Archivado de ficheros tienes tar, cpio, dar/kdar, ... pero no es tan "bonito" ni cómodo como para poner a nivel corporativo con su agente en el PC del usuario, ... :(
Si hay alguien que maneje MS-Exchange, que me corrija, pero creo que MS- Exchange lo hace internamente, que no hace falta una herramienta externa de archivado.
El dedupe también es muy útil porque reduce el espacio ocupado, otra técnica más para reducirlo.
Y no nos podemos olvidar de las quotas ;)
Para esto último os recomiendo encarecidamente ZFS bajo FreeBSD, Solaris/OpenSolaris, etc ... Una maravilla. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 21 April 2010 13:10 carlopmart wrote
Rafa Grimán wrote:
[...]
Y no nos podemos olvidar de las quotas ;)
Para esto último os recomiendo encarecidamente ZFS bajo FreeBSD, Solaris/OpenSolaris, etc ... Una maravilla.
O su homólogo|competencia en Linux: BTRFS ... que aún no se debería usar en producción ;) La verdad es que no lo he probado, pero hablan muy bien de él (de ZFS). Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Rafa Grimán wrote:
Hola :)
On Wednesday 21 April 2010 13:10 carlopmart wrote
Rafa Grimán wrote:
[...]
Y no nos podemos olvidar de las quotas ;) Para esto último os recomiendo encarecidamente ZFS bajo FreeBSD, Solaris/OpenSolaris, etc ... Una maravilla.
O su homólogo|competencia en Linux: BTRFS ... que aún no se debería usar en producción ;)
La verdad es que no lo he probado, pero hablan muy bien de él (de ZFS).
Rafa
A btrfs le queda todavía mucho camino que recorrer aunque apunte muy buenas cosas. Solo que el principal problema de btrfs ahora es Oracle: ¿mantendrá ZFS y btrfs? Lo dudo, en principio teniendo en cuenta la aceptación de ZFS y el gran despliegue en muchos entornos de producción en los que está ... Pero hay algo que corre en contra de ZFS: ¿que hará Oracle respecto a OpenSolaris?? He ahí una de las claves ... porque si Oracle finalmente no continua apoyando el desarrollo de opensolaris, ZFS se queda un poco huerfano ... Pero btrfs ahora tiene a un nuevo aliado: RedHat. RedHat liberará en la versión RHEL6 a btrfs en modo preview: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_R.... RHEL6 acaba de ser liberada ya como beta public ... Va a ser interesante saber lo que va a suceder. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 21 April 2010 14:11 carlopmart wrote
Rafa Grimán wrote:
Hola :)
On Wednesday 21 April 2010 13:10 carlopmart wrote
Rafa Grimán wrote: [...]
Y no nos podemos olvidar de las quotas ;)
Para esto último os recomiendo encarecidamente ZFS bajo FreeBSD, Solaris/OpenSolaris, etc ... Una maravilla.
O su homólogo|competencia en Linux: BTRFS ... que aún no se debería usar en producción ;)
La verdad es que no lo he probado, pero hablan muy bien de él (de ZFS).
Rafa
A btrfs le queda todavía mucho camino que recorrer aunque apunte muy buenas cosas. Solo que el principal problema de btrfs ahora es Oracle: ¿mantendrá ZFS y btrfs? Lo dudo, en principio teniendo en cuenta la aceptación de ZFS y el gran despliegue en muchos entornos de producción en los que está ... Pero hay algo que corre en contra de ZFS: ¿que hará Oracle respecto a OpenSolaris?? He ahí una de las claves ... porque si Oracle finalmente no continua apoyando el desarrollo de opensolaris, ZFS se queda un poco huerfano ...
Cierto, a ver si dicen algo definitivo ya.
Pero btrfs ahora tiene a un nuevo aliado: RedHat. RedHat liberará en la versión RHEL6 a btrfs en modo preview: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_ Release_Notes/filesystems.html#id479056. RHEL6 acaba de ser liberada ya como beta public ...
Es verdad ! En la Fedora 13 creo que también lo han incluido.
Va a ser interesante saber lo que va a suceder.
Sip, muy interesante. Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 21 Apr 2010 12:41:59 +0200, Rafa Grimán escribió:
On Tuesday 20 April 2010 19:37 Camaleón wrote
(...)
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Hum... discrepo :-)
No me lo puedo yo de creer ;)
Pues espera que contraataco O:-)
"/var" lo usan en muchas distribuciones como almacén raíz de documentos del servidor web (p. ej. yo ahora lo tengo en "/var/www", por algo relacionado con el FHS y Apache, aunque en openSUSE lo montan bajo "/ srv/").
(...)
Es decir, la tercera parte de uso total de la partición es para "/var".
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;)
No puedes archivar los datos de un servidor web :-P Imagina, te vas a YouTube para ver un vídeo en streaming y en lugar de ver un lindo gatito haciendo momerías te salta un pedazo de archivo en tar.bz2 (gatito_lindo.tar.bz2). Tampoco puedes archivar los buzones actuales de los usuarios ni los faxes. Bueno, los faxes sí, pero de hecho el directorio de archivado está en la misma ruta (/hylafax/archive), aunque supongo que con un poco de maña esto es modificable. Aún así, los usuarios necesitan tener acceso a los faxes en bruto, no pueden verlos comprimidos ni archivados porque ese formato no es accesible ni se integra con los visores de fax que usamos y la gente tiene que poder consultar faxes que se han enviado, por ejemplo, en el año 2.008 y necesitan ver los datos del número de fax que se ha marcado o la fecha programada del envío y esos datos en un archivo comprimido no se pueden consultar a simple vista.
Voy a hacer un poco de spam de un partner, pero es sólo para que lo veáis, no porque quiera venderos algo ;)
ATEMPO tiene un producto llamado ADA(M) que es un módulo de archivado. Lo que permite es pasar a otro medio todos aquellos ficheros (logs, por ejemplo, proyectos antiguos) y correos antiguos. Generalemente se pasan a cinta, pero pueden pasarse a disco. Al usuario se le instala una interfaz gráfica y el usuario va pasando ficheros y correos antiguos a cinta/disco.
Vale, pero en este caso hablamos de datos que no son antiguos, son actuales y los usuarios hacen uso a diario de ellos (lectura y escritura). Para archivo definitivo esas soluciones son perfectas.
Estaréis pensando: "Si lo dejo en manos del usuario ... jamás lo hará, se le olvidará, ...". Por eso existen la sreglas que define el admin ;) Vamos que se puede programar para que cada mes se migren los datos o bien si el fichero es mayor a X MBytes o lo que el admin decida.
El producto se integra con el backup también.
Herramientas FLOSS no he visto, bueno, he visto archivado de correo: - http://www.mailarchiva.com/ - http://www.archiveopteryx.org/overview - http://www.inovox.de/products/e-mail-archiving/e-mail-archiving - http://www.opsera.com/products/opsmailmanager/omm_overview.dot
Pero no todo junto (archivado de correo y ficheros).
Está bien... pero son soluciones muy integradas que pueden no ajustarse con los esquemas/sistemas de correo de todas las empresas.
Archivado de ficheros tienes tar, cpio, dar/kdar, ... pero no es tan "bonito" ni cómodo como para poner a nivel corporativo con su agente en el PC del usuario, ... :(
Ay, no sabes lo de "tiquismiquis" que son los usuarios con estas cosas. Como no se lo pongas en bandeja, te sacan pegas por todas partes :-/ (yo uso archivadores sencillos en ".tar.bz2" para los equipos con linux, los usuarios no quieren oír ni hablar de tener que usar soluciones de archivado dedicadas y menos aun tener que gestionarlas, cierto. Quieren ver sus carpetas y archivos tal cual tienen en sus equipos, con la misma estructura y si quieren recuperar algún documento antiguo, lo piden, ellos no mueven ni un dedo. Pensándolo bien, creo que es mejor así...). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 21 April 2010 13:16 Camaleón wrote
El Wed, 21 Apr 2010 12:41:59 +0200, Rafa Grimán escribió:
On Tuesday 20 April 2010 19:37 Camaleón wrote
(...)
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Hum... discrepo :-)
No me lo puedo yo de creer ;)
Pues espera que contraataco O:-)
xD
"/var" lo usan en muchas distribuciones como almacén raíz de documentos del servidor web (p. ej. yo ahora lo tengo en "/var/www", por algo relacionado con el FHS y Apache, aunque en openSUSE lo montan bajo "/ srv/").
(...)
Es decir, la tercera parte de uso total de la partición es para "/var".
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;)
No puedes archivar los datos de un servidor web :-P
Imagina, te vas a YouTube para ver un vídeo en streaming y en lugar de ver un lindo gatito haciendo momerías te salta un pedazo de archivo en tar.bz2 (gatito_lindo.tar.bz2).
Ahí entraría la parte de HSM (aka almacenamiento jerárquico). Tienes 3 niveles de almacenamiento típicamente: 1.- elevada velocidad (FC/SAS): de esto tienes "poco" y tienes los datos usados más recientemente 2.- disco de baja velocidad pero elevada densidad (SATA): aquí tienes datos que no se usan mucho, pero que alguna vez alguien lo ha pedido 3.- cinta: aquí tienes los datos que casi no se usan Pasado el punto 3, se archiva todo ... o se borra ;)
Tampoco puedes archivar los buzones actuales de los usuarios ni los faxes. Bueno, los faxes sí, pero de hecho el directorio de archivado está en la misma ruta (/hylafax/archive), aunque supongo que con un poco de maña esto es modificable.
Por eso tienes dos opciones: 1.- el usuairo tiene derecho a gestionar el archivado por lo que un usuario "correcto" pasará al archivo todos los correos de más de 6 meses o un año y los recuperará si los necesita 2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos Una tercera opción es juntar ambas de forma que automáticamente se migran los correos pasado un tiempo y si el usuario quiere recuperarlo, lo recupera.
Aún así, los usuarios necesitan tener acceso a los faxes en bruto, no pueden verlos comprimidos ni archivados porque ese formato no es accesible ni se integra con los visores de fax que usamos y la gente tiene que poder consultar faxes que se han enviado, por ejemplo, en el año 2.008 y necesitan ver los datos del número de fax que se ha marcado o la fecha programada del envío y esos datos en un archivo comprimido no se pueden consultar a simple vista.
Para eso el ADA(M) tiene una interfaz gráfica (muy similar al explorador de disco) que te permite recuperar los ficheros. En el caso de los fax u otros ficheros (ofimática, vídeos, ...) el uso de HSM es batsante cómodo porque imaginémonos que tienes el servidor con lo siguiente: nivel 1: 5 TB en SAS nivel 2: 20 TB en SATA nivel 3: 100 TB en cinta Los ficheros más usados, se encuentran en los discos SAS, los menos usados en SATA y los que están llenos de polvo en cinta. Suponemos que el sistema de ficheros que exportas es /mnt/exportado/ y el usuario lo mapea a su PC con MS-Windows como F: Bien, pues el usuario verá que su F: tiene un tamaño de 100 + 50 + 5 TB = 155 TB. El usuario no sabe (ni tiene por qué sabr) que realmente hay 3 niveles de almacenamiento. Así que el usuario pincha en el fichero, lo borra, lo copia, lo mueve, ... como si realmente fuera un único disco. Dependiendo del HSM y del tipo de fichero, se pueden hacer unsa cosas u otras, por ejemplo, en vídeo (TV, cine, ...) el HSM puede hacer una de dos: - dejar los primeros segundos en el nivel 1 y el resto migrarlo - migrar ciertas partes, por ejemplo, del minuto 1 al 7, del 8 al 9 los mirga a nivel 2 dejando el resto de minutos en nivel 1. Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line. A su vez, el HSM se puede integrar con archivado y backup de forma que mezclas todo ;)
Voy a hacer un poco de spam de un partner, pero es sólo para que lo veáis, no porque quiera venderos algo ;)
ATEMPO tiene un producto llamado ADA(M) que es un módulo de archivado. Lo que permite es pasar a otro medio todos aquellos ficheros (logs, por ejemplo, proyectos antiguos) y correos antiguos. Generalemente se pasan a cinta, pero pueden pasarse a disco. Al usuario se le instala una interfaz gráfica y el usuario va pasando ficheros y correos antiguos a cinta/disco.
Vale, pero en este caso hablamos de datos que no son antiguos, son actuales y los usuarios hacen uso a diario de ellos (lectura y escritura).
Para archivo definitivo esas soluciones son perfectas.
Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar.
Estaréis pensando: "Si lo dejo en manos del usuario ... jamás lo hará, se le olvidará, ...". Por eso existen la sreglas que define el admin ;) Vamos que se puede programar para que cada mes se migren los datos o bien si el fichero es mayor a X MBytes o lo que el admin decida.
El producto se integra con el backup también.
Herramientas FLOSS no he visto, bueno, he visto archivado de correo: - http://www.mailarchiva.com/ - http://www.archiveopteryx.org/overview - http://www.inovox.de/products/e-mail-archiving/e-mail-archiving - http://www.opsera.com/products/opsmailmanager/omm_overview.dot
Pero no todo junto (archivado de correo y ficheros).
Está bien... pero son soluciones muy integradas que pueden no ajustarse con los esquemas/sistemas de correo de todas las empresas.
Cierto. Hoy por hoy en FLOSS hay poco :(
Archivado de ficheros tienes tar, cpio, dar/kdar, ... pero no es tan "bonito" ni cómodo como para poner a nivel corporativo con su agente en el PC del usuario, ... :(
Ay, no sabes lo de "tiquismiquis" que son los usuarios con estas cosas. Como no se lo pongas en bandeja, te sacan pegas por todas partes :-/
Sí, sí lo sé ...
(yo uso archivadores sencillos en ".tar.bz2" para los equipos con linux, los usuarios no quieren oír ni hablar de tener que usar soluciones de archivado dedicadas y menos aun tener que gestionarlas, cierto. Quieren ver sus carpetas y archivos tal cual tienen en sus equipos, con la misma estructura y si quieren recuperar algún documento antiguo, lo piden, ellos no mueven ni un dedo. Pensándolo bien, creo que es mejor así...).
Cierto, que no lo toquen ;) De ahí que los HSM sean tan cómodos. Rafa PD Se me olvidaba. A todo esto, usar DAM (Digital Asset Management) también es útil, pero como siempre ... supone cambiar cosas, migraciones, cambio de cómo se trabaja, ... Los DAM son similares a lso CMS, pero para cualquier tipo de dato digital, no sólo ficheros ofimáticos. -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 21 Apr 2010 14:32:01 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 13:16 Camaleón wrote
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;)
No puedes archivar los datos de un servidor web :-P
Imagina, te vas a YouTube para ver un vídeo en streaming y en lugar de ver un lindo gatito haciendo momerías te salta un pedazo de archivo en tar.bz2 (gatito_lindo.tar.bz2).
Ahí entraría la parte de HSM (aka almacenamiento jerárquico). Tienes 3 niveles de almacenamiento típicamente: 1.- elevada velocidad (FC/SAS): de esto tienes "poco" y tienes los datos usados más recientemente 2.- disco de baja velocidad pero elevada densidad (SATA): aquí tienes datos que no se usan mucho, pero que alguna vez alguien lo ha pedido 3.- cinta: aquí tienes los datos que casi no se usan
Pasado el punto 3, se archiva todo ... o se borra ;)
No sé... yo no veo ese sistema para un servidor web. Por ejemplo, en las típicas empresas de hospedaje compartido, no hay apenas archivado de datos (sólo se almacenan los registros de acceso y durante poco tiempo) pero dudo mucho que sigan un sistema jerarquizado como el que planteas... salvo que lo pagues, claro está, porque eso cuesta pasta y como no contrates un servidor dedicado o virtual, dudo mucho que lo ofrezcan >:-)
Tampoco puedes archivar los buzones actuales de los usuarios ni los faxes. Bueno, los faxes sí, pero de hecho el directorio de archivado está en la misma ruta (/hylafax/archive), aunque supongo que con un poco de maña esto es modificable.
Por eso tienes dos opciones:
1.- el usuairo tiene derecho a gestionar el archivado por lo que un usuario "correcto" pasará al archivo todos los correos de más de 6 meses o un año y los recuperará si los necesita
Je, je... "usuario correcto" no existe en mi vocabulario >:-)
2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos
Eso lo puedes hacer pero dejando al usuario al margen y no tocando para nada sus mensajes locales actuales. Yo puedo hacer una copia de seguridad de sus correos o de la configuración del cliente de correo (agenda contactos, etc...), pero no puedo decidir qué le archivo y qué no, no me parece correcto porque los datos archivados son datos que le quito de su alcance y los puede necesitar :-/
Una tercera opción es juntar ambas de forma que automáticamente se migran los correos pasado un tiempo y si el usuario quiere recuperarlo, lo recupera.
Ufff. Ya te digo yo que no podría hacerlo, me cortan la cabeza. Yo les hago la copia de seguridad y poco más. Ellos son los que tienen que decidir qué quieren eliminar o mantener siempre accesible.
Aún así, los usuarios necesitan tener acceso a los faxes en bruto, no pueden verlos comprimidos ni archivados porque ese formato no es accesible ni se integra con los visores de fax que usamos y la gente tiene que poder consultar faxes que se han enviado, por ejemplo, en el año 2.008 y necesitan ver los datos del número de fax que se ha marcado o la fecha programada del envío y esos datos en un archivo comprimido no se pueden consultar a simple vista.
Para eso el ADA(M) tiene una interfaz gráfica (muy similar al explorador de disco) que te permite recuperar los ficheros.
En el caso de los fax u otros ficheros (ofimática, vídeos, ...) el uso de HSM es batsante cómodo porque imaginémonos que tienes el servidor con lo siguiente: nivel 1: 5 TB en SAS nivel 2: 20 TB en SATA nivel 3: 100 TB en cinta
Los ficheros más usados, se encuentran en los discos SAS, los menos usados en SATA y los que están llenos de polvo en cinta.
Suponemos que el sistema de ficheros que exportas es /mnt/exportado/ y el usuario lo mapea a su PC con MS-Windows como F:
Bien, pues el usuario verá que su F: tiene un tamaño de 100 + 50 + 5 TB = 155 TB. El usuario no sabe (ni tiene por qué sabr) que realmente hay 3 niveles de almacenamiento. Así que el usuario pincha en el fichero, lo borra, lo copia, lo mueve, ... como si realmente fuera un único disco.
Dependiendo del HSM y del tipo de fichero, se pueden hacer unsa cosas u otras, por ejemplo, en vídeo (TV, cine, ...) el HSM puede hacer una de dos:
- dejar los primeros segundos en el nivel 1 y el resto migrarlo
- migrar ciertas partes, por ejemplo, del minuto 1 al 7, del 8 al 9 los mirga a nivel 2 dejando el resto de minutos en nivel 1.
Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line.
A su vez, el HSM se puede integrar con archivado y backup de forma que mezclas todo ;)
Si la teoría está muy bien, Rafa, pero esa solución no sirve para los faxes (no sólo se trata de almacenar y clasificar los documentos de fax sino de "interpretarlos" para que el usuario sepa si es el archivo que busca o no) >:-). Como sistema de archivado general, vale.
Vale, pero en este caso hablamos de datos que no son antiguos, son actuales y los usuarios hacen uso a diario de ellos (lectura y escritura).
Para archivo definitivo esas soluciones son perfectas.
Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar.
Bueeenooo, no sé yo... el propio cliente de correo hace las funciones de archivador. O debería, si hicieran clientes de correo profesionales en lugar de tanta integración con las redes sociales :-P. Al fin y al cabo, los datos archivados están en algún lado (disco duro local, disco en red, cinta, Internet...) el cliente de correo sólo tendría que "enlazar" con el archivador y mostrarlo / administrarlo como tal (por ejemplo, no incluir esas carpetas en la rutina de copia de seguridad, mantener los datos comprimidos y descomprimirlos al vuelo si el usuario ejecuta alguna acción sobre esos corroes, mantener el estado de los mensajes, permitir indexar igualmente su contenido, etc...). (...)
PD Se me olvidaba. A todo esto, usar DAM (Digital Asset Management) también es útil, pero como siempre ... supone cambiar cosas, migraciones, cambio de cómo se trabaja, ... Los DAM son similares a lso CMS, pero para cualquier tipo de dato digital, no sólo ficheros ofimáticos.
Buf, vaya "monstruo", eso hace de todo (de la wikipedia): "(...) The term "digital asset management" (DAM) also refers to the protocol for downloading, renaming, backing up, rating, grouping, archiving, optimizing, maintaining, thinning, and exporting files." Creo que con un DMS sencillito ya sería suficiente O:-). Bueno, vale, para algunos sectores de la industria no, necesitan una mejor administración de los contenidos y un mayor control del espacio y la ubicación exacta de las copias, es cierto. Con sistemas como estos que hacen todo y de forma automática nos quedamos sin curro en unos años :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 21 April 2010 15:37 Camaleón wrote
El Wed, 21 Apr 2010 14:32:01 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 13:16 Camaleón wrote
Por eso digo que hay que archivar. El uso de archivado es muy bueno y muy utilizado en servidores de correo porque quita mucha morralla (aka correos antiguos que el usuario ni se acuerda que existe ;)
No puedes archivar los datos de un servidor web :-P
Imagina, te vas a YouTube para ver un vídeo en streaming y en lugar de ver un lindo gatito haciendo momerías te salta un pedazo de archivo en tar.bz2 (gatito_lindo.tar.bz2).
Ahí entraría la parte de HSM (aka almacenamiento jerárquico). Tienes 3
niveles de almacenamiento típicamente: 1.- elevada velocidad (FC/SAS): de esto tienes "poco"
y tienes los datos usados más recientemente
2.- disco de baja velocidad pero elevada densidad (SATA): aquí tienes datos que no se usan mucho, pero que alguna vez alguien lo ha pedido
3.- cinta: aquí tienes los datos que casi no se usan
Pasado el punto 3, se archiva todo ... o se borra ;)
No sé... yo no veo ese sistema para un servidor web.
Pues es lo que están usando todas las TVs del mundo ;) Incluyendo NBA. Además de las empresas de postproducción y de efectos especiales ... y eso es tiempo real ;)
Por ejemplo, en las típicas empresas de hospedaje compartido, no hay apenas archivado de datos (sólo se almacenan los registros de acceso y durante poco tiempo) pero dudo mucho que sigan un sistema jerarquizado como el que planteas... salvo que lo pagues, claro está, porque eso cuesta pasta y como no contrates un servidor dedicado o virtual, dudo mucho que lo ofrezcan >:-)
Si pagas, lo hacen ;)
Tampoco puedes archivar los buzones actuales de los usuarios ni los faxes. Bueno, los faxes sí, pero de hecho el directorio de archivado está en la misma ruta (/hylafax/archive), aunque supongo que con un poco de maña esto es modificable.
Por eso tienes dos opciones: 1.- el usuairo tiene derecho a gestionar el archivado por lo que un usuario "correcto" pasará al archivo todos los correos de más de 6 meses o un año y los recuperará si los necesita
Je, je... "usuario correcto" no existe en mi vocabulario >:-)
Por eso lo puse entre comillas ;)
2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos
Eso lo puedes hacer pero dejando al usuario al margen y no tocando para nada sus mensajes locales actuales. Yo puedo hacer una copia de seguridad de sus correos o de la configuración del cliente de correo (agenda contactos, etc...), pero no puedo decidir qué le archivo y qué no, no me parece correcto porque los datos archivados son datos que le quito de su alcance y los puede necesitar :-/
Para eso hay una interfaz/GUI para el usuario, para que recupere lo que necesita cuando lo necesita. Obviamente, no vas a migrar los correos de ayer. Migras los de hace un año, por ejemplo.
Una tercera opción es juntar ambas de forma que automáticamente se migran los correos pasado un tiempo y si el usuario quiere recuperarlo, lo recupera.
Ufff. Ya te digo yo que no podría hacerlo, me cortan la cabeza. Yo les hago la copia de seguridad y poco más. Ellos son los que tienen que decidir qué quieren eliminar o mantener siempre accesible.
Pero es que no se eliminan, se mueven de un sitio a otro. Otra cosa, si al jefe le exolicas que migrando los correos a una cinta va a ahorrar en espacio, consumo eléctrico (tanto porque la cinta no consume a menos que se use como el que no produce calor), ... Lo impone. Te lo digo porque lo he visto. Y cuando las órdenes vienen de arriba ...
Aún así, los usuarios necesitan tener acceso a los faxes en bruto, no pueden verlos comprimidos ni archivados porque ese formato no es accesible ni se integra con los visores de fax que usamos y la gente tiene que poder consultar faxes que se han enviado, por ejemplo, en el año 2.008 y necesitan ver los datos del número de fax que se ha marcado o la fecha programada del envío y esos datos en un archivo comprimido no se pueden consultar a simple vista.
Para eso el ADA(M) tiene una interfaz gráfica (muy similar al explorador de disco) que te permite recuperar los ficheros.
En el caso de los fax u otros ficheros (ofimática, vídeos, ...) el uso de HSM es batsante cómodo porque imaginémonos que tienes el servidor con
lo siguiente: nivel 1: 5 TB en SAS nivel 2: 20 TB en SATA nivel 3: 100 TB en cinta
Los ficheros más usados, se encuentran en los discos SAS, los menos usados en SATA y los que están llenos de polvo en cinta.
Suponemos que el sistema de ficheros que exportas es /mnt/exportado/ y el usuario lo mapea a su PC con MS-Windows como F:
Bien, pues el usuario verá que su F: tiene un tamaño de 100 + 50 + 5 TB = 155 TB. El usuario no sabe (ni tiene por qué sabr) que realmente hay 3 niveles de almacenamiento. Así que el usuario pincha en el fichero, lo borra, lo copia, lo mueve, ... como si realmente fuera un único disco.
Dependiendo del HSM y del tipo de fichero, se pueden hacer unsa cosas u otras, por ejemplo, en vídeo (TV, cine, ...) el HSM puede hacer una de
dos: - dejar los primeros segundos en el nivel 1 y el resto migrarlo
- migrar ciertas partes, por ejemplo, del minuto 1 al 7, del 8 al 9 los mirga a nivel 2 dejando el resto de minutos en nivel 1.
Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line.
A su vez, el HSM se puede integrar con archivado y backup de forma que mezclas todo ;)
Si la teoría está muy bien, Rafa, pero esa solución no sirve para los faxes (no sólo se trata de almacenar y clasificar los documentos de fax sino de "interpretarlos" para que el usuario sepa si es el archivo que busca o no) >:-). Como sistema de archivado general, vale.
Sí vale porque se migran los fax (u otros tipos de ficheros) que tienen una edad determinada, por ejemplo, todos los fax más antiguos de 1 año. Te lo digo porque lo hemos montado y funciona. No sólo nosotros, IBM también lo monta y EMC y muchos más. Lo hacemos/hacen para todo tipo de ficheros y el cliente no se da cuenta. Nosotros lo hemos instalado en clientes para vídeo, audio, imágenes, documentos ofimáticos (incluyendo fax), datos HPC, ... y los usuarios no se enteran, te lo garantizo.
Vale, pero en este caso hablamos de datos que no son antiguos, son actuales y los usuarios hacen uso a diario de ellos (lectura y escritura).
Para archivo definitivo esas soluciones son perfectas.
Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar.
Bueeenooo, no sé yo... el propio cliente de correo hace las funciones de archivador. O debería, si hicieran clientes de correo profesionales en lugar de tanta integración con las redes sociales :-P.
x"D QUé manía les tengo a las redes sociales >:-|
Al fin y al cabo, los datos archivados están en algún lado (disco duro local, disco en red, cinta, Internet...) el cliente de correo sólo tendría que "enlazar" con el archivador y mostrarlo / administrarlo como tal (por ejemplo, no incluir esas carpetas en la rutina de copia de seguridad, mantener los datos comprimidos y descomprimirlos al vuelo si el usuario ejecuta alguna acción sobre esos corroes, mantener el estado de los mensajes, permitir indexar igualmente su contenido, etc...).
No te sé decir exactamente cómo lo hace cada sw de archivado, cada uno lo hae a su manera. Con el MS-Exchange, creo que se hace eso, pero no te lo sé decir a ciencia cierta 0:)
PD Se me olvidaba. A todo esto, usar DAM (Digital Asset Management) también es útil, pero como siempre ... supone cambiar cosas, migraciones, cambio de cómo se trabaja, ... Los DAM son similares a lso CMS, pero para cualquier tipo de dato digital, no sólo ficheros ofimáticos.
Buf, vaya "monstruo", eso hace de todo (de la wikipedia):
"(...) The term "digital asset management" (DAM) also refers to the protocol for downloading, renaming, backing up, rating, grouping, archiving, optimizing, maintaining, thinning, and exporting files."
Creo que con un DMS sencillito ya sería suficiente O:-). Bueno, vale, para algunos sectores de la industria no, necesitan una mejor administración de los contenidos y un mayor control del espacio y la ubicación exacta de las copias, es cierto.
Con sistemas como estos que hacen todo y de forma automática nos quedamos sin curro en unos años :-)
No te creas. Los CMS/DAM/MAM/ECMS/PLM se tienen que configurar y administrar y eso no es fácil ;) Hay mucha integración por detrás, BBDD, servidores de ficheros, correo, web, ... Además, como el DAM te permite trabajar con difrerentes tipos de ficheros (a diferencia de los CMS), tienes que saber dimensionarlo bien, separar los servicios, ... Casi se me olvida. Un DAM es muy valorado en países "organizados", en países como España en los que todos hacemos lo que nos da la gan cuando nos da la gana ... el DAM es más un dolor de cabeza que una solución :( Estos inventos son muy buenos cunado toda la organización sigue unas normas. Como aquí las normas están para saltártelas ... pues si dice el jefe que hay que almacenar los documentos en el servidor ... que los almacene su abuela es la respuesta más educada que va a recibir. Por ejemplo, ¿cuántos habéis sufrido al SharePoint de MS? Pues eso es un CMS, imagínate si además añades vídeo y audio ... No te quiero contar la que se lía. Yo lo he sufrido y no es poruqe sea de MS es porque la gente no seguí las normas y al final había documentos repetidos, no sabías cuál era la versión última, qué revisiones se habían hecho, quién las había hecho, de qué iba el documento, ... Rafa -- Rafa Grimán Systems Engineer Silicon Graphics, S.A. Sociedad Unipersonal Plaza del Descubridor Diego de Ordás 3 Tel: +34 91 398 42 00 Edificio Santa Engracia 120 Fax: +34 91 398 42 01 28003 Madrid Mobile: +34 628 11 79 40 Spain E-mail: rgriman@sgi.com http://www.sgi.com Skype: rgriman NIF - A79415873. Inscrita en el Registro Mercantil de Madrid Tomo 207, Folio 104, Hoja M-4186 el 5-7-90 __________________________________________________________________________ NB: INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL. IT IS INTENDED SOLELY FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED, DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT. IF YOU ARE NOT THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE, DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED COPIES. NB: LA INFORMACION CONTENIDA EN ESTE MENSAJE ES CONFIDENCIAL DE SGI. ESTA DIRIGIDA UNICAMENTE A LA PERSONA(S) A LA CUAL SE ENVIA Y NO PUEDE SER COPIADA, UTILIZADA, DIVULGADA O DISTRIBUIDA A OTROS SIN EL CONSENTIMIENTO PREVIO DE SGI. SI USTED NO ES EL DESTINATARIO INDICADO HAGA EL FAVOR DE NOTIFICARMELO POR MAIL O POR TELEFONO, BORRE EL MENSAJE DE SU SISTEMA INMEDIATAMENTE Y DESTRUYA CUALQUIER COPIA IMPRESA "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wed, 21 Apr 2010 16:17:29 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 15:37 Camaleón wrote
2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos
Eso lo puedes hacer pero dejando al usuario al margen y no tocando para nada sus mensajes locales actuales. Yo puedo hacer una copia de seguridad de sus correos o de la configuración del cliente de correo (agenda contactos, etc...), pero no puedo decidir qué le archivo y qué no, no me parece correcto porque los datos archivados son datos que le quito de su alcance y los puede necesitar :-/
Para eso hay una interfaz/GUI para el usuario, para que recupere lo que necesita cuando lo necesita. Obviamente, no vas a migrar los correos de ayer. Migras los de hace un año, por ejemplo.
Siempre y cuando el usuario pueda acceder de la misma forma que accede a los correos que tiene en el cliente (es decir, que se pueda integrar con el programa de correo, que pueda ejecutar búsquedas sobre el archivador) vale. Si tiene que mantener la aplicación del archivador abierta en paralelo, además del cliente de correo, para poder consultar los mensajes de hace un año, mal. ¿No he dicho alguna vez que tengo correos del año 2000? Y eso no es nada, tengo usuarios que mantienen mensajes del año 1997, son auténticos "recolectores digitales" y si nombro el término "archivar mensajes" me mandan a paseo. Y no sólo usuarios, también los jefes tienen "correitis" :-P
Ufff. Ya te digo yo que no podría hacerlo, me cortan la cabeza. Yo les hago la copia de seguridad y poco más. Ellos son los que tienen que decidir qué quieren eliminar o mantener siempre accesible.
Pero es que no se eliminan, se mueven de un sitio a otro. Otra cosa, si al jefe le exolicas que migrando los correos a una cinta va a ahorrar en espacio, consumo eléctrico (tanto porque la cinta no consume a menos que se use como el que no produce calor), ... Lo impone. Te lo digo porque lo he visto. Y cuando las órdenes vienen de arriba ...
Si se "adereza" bien, podrían dar el visto bueno, sí :-) (...)
Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line.
A su vez, el HSM se puede integrar con archivado y backup de forma que mezclas todo ;)
Si la teoría está muy bien, Rafa, pero esa solución no sirve para los faxes (no sólo se trata de almacenar y clasificar los documentos de fax sino de "interpretarlos" para que el usuario sepa si es el archivo que busca o no) >:-). Como sistema de archivado general, vale.
Sí vale porque se migran los fax (u otros tipos de ficheros) que tienen una edad determinada, por ejemplo, todos los fax más antiguos de 1 año. Te lo digo porque lo hemos montado y funciona. No sólo nosotros, IBM también lo monta y EMC y muchos más. Lo hacemos/hacen para todo tipo de ficheros y el cliente no se da cuenta.
Nosotros lo hemos instalado en clientes para vídeo, audio, imágenes, documentos ofimáticos (incluyendo fax), datos HPC, ... y los usuarios no se enteran, te lo garantizo.
Serán soluciones integradas, es decir, que requieren la instalación de programas dedicados para gestionar esos archivadores. Ese tipo de soluciones te obliga a replantear por completo tu estrategia. Hombre, no te digo que con un volumen de datos muy elevado no venga bien :-} Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Wednesday 21 April 2010 16:49 Camaleón wrote
El Wed, 21 Apr 2010 16:17:29 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 15:37 Camaleón wrote
2.- como admin, estableces reglas de migración que auto-
máticamente t emigran los correos más antiguos
Eso lo puedes hacer pero dejando al usuario al margen y no tocando para nada sus mensajes locales actuales. Yo puedo hacer una copia de seguridad de sus correos o de la configuración del cliente de correo (agenda contactos, etc...), pero no puedo decidir qué le archivo y qué no, no me parece correcto porque los datos archivados son datos que le quito de su alcance y los puede necesitar :-/
Para eso hay una interfaz/GUI para el usuario, para que recupere lo que necesita cuando lo necesita. Obviamente, no vas a migrar los correos de ayer. Migras los de hace un año, por ejemplo.
Siempre y cuando el usuario pueda acceder de la misma forma que accede a los correos que tiene en el cliente (es decir, que se pueda integrar con el programa de correo, que pueda ejecutar búsquedas sobre el archivador) vale.
Si tiene que mantener la aplicación del archivador abierta en paralelo, además del cliente de correo, para poder consultar los mensajes de hace un año, mal.
Eso ya no te lo sé decir porque no lo tengo. Yo uso POP y soy muy feliz ;) Pero los casos que conozco de ATEMPO, tienen a los usuarios contentos. Les puedo preguntar a ver cómo es.
¿No he dicho alguna vez que tengo correos del año 2000? Y eso no es nada, tengo usuarios que mantienen mensajes del año 1997, son auténticos "recolectores digitales" y si nombro el término "archivar mensajes" me mandan a paseo. Y no sólo usuarios, también los jefes tienen "correitis" :-P
Te remito a los casos de usuario que conozco, no hay problema. No seas tan "negativa"/"rehacia" ;) Con esto no quiero obligarte o convencerte a usarlo, pero sí que lo tengas en cuenta y que te hagan demos, casi todos los SW de backup te hacen también archivado. Los habrá que lo hacen mejor y los habrá que lo hacen peor, como siempre. Yo también tengo muchos correos (~90 mil) desde hace mucho tiempo (pre 2000), y Carlos de vez en cuando nos lo dice también. Pero nosotros tres somos "diferentes". Los casos que conozco de ATEMPO (digo ATEMPO porque es con quién más trabajamos, pero hay muchos más) los usuarios no se quejan (más de lo normal ;) Ten en cuenta que el hagas lo que hagas el usuario se va a quejar :(
Ufff. Ya te digo yo que no podría hacerlo, me cortan la cabeza. Yo les hago la copia de seguridad y poco más. Ellos son los que tienen que decidir qué quieren eliminar o mantener siempre accesible.
Pero es que no se eliminan, se mueven de un sitio a otro. Otra cosa, si al jefe le exolicas que migrando los correos a una cinta va a ahorrar en espacio, consumo eléctrico (tanto porque la cinta no consume a menos que se use como el que no produce calor), ... Lo impone. Te lo digo porque lo he visto. Y cuando las órdenes vienen de arriba ...
Si se "adereza" bien, podrían dar el visto bueno, sí :-)
Es que un poco de marketing (aka miedo) viene bien de vez en cuando ;)
Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line.
A su vez, el HSM se puede integrar con archivado y backup de forma que mezclas todo ;)
Si la teoría está muy bien, Rafa, pero esa solución no sirve para los faxes (no sólo se trata de almacenar y clasificar los documentos de fax sino de "interpretarlos" para que el usuario sepa si es el archivo que busca o no) >:-). Como sistema de archivado general, vale.
Sí vale porque se migran los fax (u otros tipos de ficheros) que tienen una edad determinada, por ejemplo, todos los fax más antiguos de 1 año. Te lo digo porque lo hemos montado y funciona. No sólo nosotros, IBM también lo monta y EMC y muchos más. Lo hacemos/hacen para todo tipo de ficheros y el cliente no se da cuenta.
Nosotros lo hemos instalado en clientes para vídeo, audio, imágenes, documentos ofimáticos (incluyendo fax), datos HPC, ... y los usuarios no se enteran, te lo garantizo.
Serán soluciones integradas, es decir, que requieren la instalación de programas dedicados para gestionar esos archivadores. Ese tipo de soluciones te obliga a replantear por completo tu estrategia.
No te creas, lo único que tienes que plantearte (que no replantearte) son las reglas de migración.
Hombre, no te digo que con un volumen de datos muy elevado no venga bien :-}
El tamaño del vlumen es relativo. Lo que para la nosotros es grande ... para la NBA es inexistente ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-04-21 08:55, Rafa Grimán wrote:
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Una base de datos como mysql va en /var, y crece. Un caché de updates también iría en /var, y crecería. Un servidor de logs, idem. Un servidor de correo imap, ídem. :-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkvPR2MACgkQja8UbcUWM1z7vwEAjQB6BWTbw0JgS9jwZpTibRnI Y4JFLdq1yjQvVAu1HvgA/0wHtl6TYaGRlcLcIygUI0O09S4aGMI4OgLKuXWIYzny =y+zC -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Wednesday 21 April 2010 20:43 Carlos E. R. wrote
On 2010-04-21 08:55, Rafa Grimán wrote:
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Una base de datos como mysql va en /var, y crece. Un caché de updates también iría en /var, y crecería. Un servidor de logs, idem. Un servidor de correo imap, ídem.
:-)
Una base de datos no crece como crece el correo, es un crecimiento muy pequeño ... si la diseñas bien - por ejemplo, si apunta a ficheros y no los incluye en la propia BBDD - la BBDD debe ir en su propia partición con RAID 10 y un gestor de volúmenes (como LVM) El correo y los logs, ya lo he comentado: archivado. Mano de santo. Además de los backups ;) Caché (de Squid, por ejemplo): un buen admin: - _NO_ deja que la caché crezca "hasta el infinito y más allá" ;) Cachear todo no es útil y además no podemos competir ni con Google ni con Akamai ni con "Way back machine" ;) Es más importante tener discos rápidos que muchas cosas cacheadas y definir bien lo que sea cachea y durante cuánto tiempo - la caché en su propio sistema de ficheros, igual que en las BBDD ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-04-22 a las 11:20 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 20:43 Carlos E. R. wrote
On 2010-04-21 08:55, Rafa Grimán wrote:
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Una base de datos como mysql va en /var, y crece. Un caché de updates también iría en /var, y crecería. Un servidor de logs, idem. Un servidor de correo imap, ídem.
:-)
Una base de datos no crece como crece el correo, es un crecimiento muy pequeño ... si la diseñas bien
- por ejemplo, si apunta a ficheros y no los incluye en la propia BBDD
Pueden ser simplemente millones de datos "normales".
- la BBDD debe ir en su propia partición con RAID 10 y un gestor de volúmenes (como LVM)
Puede, pero seguirá estando jerarquicamente debajo de /var, luego /var crece >:-)
El correo y los logs, ya lo he comentado: archivado. Mano de santo. Además de los backups ;)
Siempre y cuando la política de la empresa te deje. Pueden exigirte tener en linea varios gigas de espacio para cada usuario en imap, en plan gmail.
Caché (de Squid, por ejemplo): un buen admin:
- _NO_ deja que la caché crezca "hasta el infinito y más allá" ;) Cachear todo no es útil y además no podemos competir ni con Google ni con Akamai ni con "Way back machine" ;) Es más importante tener discos rápidos que muchas cosas cacheadas y definir bien lo que sea cachea y durante cuánto tiempo
Imagino que le puedes poner límite. Pero a lo mejor lo que cacheas son los servidores de actualización de los varios linuxes y windoses que tienes, y eso es un porrón de gigas.
- la caché en su propio sistema de ficheros, igual que en las BBDD
;)
Puede, pero seguirá estando jerarquicamente debajo de /var, luego /var crece >:-) El /var puede ser muy grande. Aunque lo gestiones bien, lo repartas, lo archives en tres capas, puede ser enorme. Es a donde van los datos que no son propiedad de un usuario sino de todos, es decir, los datos que se "sirven" desde el servidor. Mira, yo en casita tengo ahora mismo 3.4 gigas debajo de /var, según "du - -hc /var" Y he tenido más. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkvQcRgACgkQtTMYHG2NR9We2wCdGfsiSkF3xkCrkSJeW5THiM2E jt4AnR3J8ackOb3xoDV1kc0jAg5MDTSN =8ysH -----END PGP SIGNATURE-----
Hola :) On Thursday 22 April 2010 17:53 Carlos E. R. wrote
El 2010-04-22 a las 11:20 +0200, Rafa Grimán escribió:
On Wednesday 21 April 2010 20:43 Carlos E. R. wrote
On 2010-04-21 08:55, Rafa Grimán wrote:
/var o /tmp _NO_ crecen. Me explico: los logs hay que rotarlos y archivarlos (CD, cinta, floppy, ...) e incluso hacer backups, pero no se quedan en disco por lo que vas liberando espacio.
Una base de datos como mysql va en /var, y crece. Un caché de updates también iría en /var, y crecería. Un servidor de logs, idem. Un servidor de correo imap, ídem.
:-)
Una base de datos no crece como crece el correo, es un crecimiento muy pequeño ... si la diseñas bien
- por ejemplo, si apunta a ficheros y no los incluye en la propia BBDD
Pueden ser simplemente millones de datos "normales".
Sí, pero si los ficheros están fuera y está bien diseñada para que no haya datos repetidos, el tamaño es menor. Obviamente, puedes tener BBDD muy grandes, nosotros tenemos en EEUU un cliente con un BBDD de +1 TByte. Pero de esas, creeme que hay MUUUUUUY pocas y su crecimiento no es de 1 TByte al año y, aunque fuera de 1 TByte al año, tampoco es un crecimiento espectacular. Un servidor de ficheros crece mucho más que eso y en el mundo de Media, 1 TByte es casi lo que haces el primer día y te hablo de servidor de ficheros ;)
- la BBDD debe ir en su propia partición con RAID 10 y un gestor de
volúmenes (como LVM)
Puede, pero seguirá estando jerarquicamente debajo de /var, luego /var crece >:-)
Jerárquicamente, pero en cuanto a sistema d eficheros no, la BBDD estaría en un sistema de ficheros separado.
El correo y los logs, ya lo he comentado: archivado. Mano de santo. Además de los backups ;)
Siempre y cuando la política de la empresa te deje. Pueden exigirte tener en linea varios gigas de espacio para cada usuario en imap, en plan gmail.
El acrhivado puede está shelved cuando lo sacas de la librería o del jukebox de CD/DVD/BR. Sacar cintas de una librería para backup es bastante normal (hay que evitar que backup y datos estén físicamente próximos). El archivado (a cinta o a CD/DVD/BR) no significa necesarioamente que te lo llevas a otra oficina, a un banco, a un vault o similar, significa que no lo tienes en disco principal. Es decir, puede estar dentro de la librería de cintas. También hay que tener en cuenta un tipo de archivado "especial" que es lo que se llama copia legal y es básicamente lo que exige la ley en cuanto a determinados datos digitales: que tienes que tener una copia para revisiones legales durante no sé cuánto tiempo. Se tiene que guardar en un medio inalterable (WORM) y tienes que garantizar su lectura durante ese tiempo que exige la ley.
Caché (de Squid, por ejemplo): un buen admin: - _NO_ deja que la caché crezca "hasta el infinito y más allá" ;)
Cachear todo no es útil y además no podemos competir ni con Google ni con Akamai ni con "Way back machine" ;) Es más importante tener discos rápidos que muchas cosas cacheadas y definir bien lo que sea cachea y durante cuánto tiempo
Imagino que le puedes poner límite. Pero a lo mejor lo que cacheas son los servidores de actualización de los varios linuxes y windoses que tienes, y eso es un porrón de gigas.
¿De cuánto son los HDD de hoy en día? También los puedes archivar en DVD ;)
- la caché en su propio sistema de ficheros,
igual que en las BBDD
;)
Puede, pero seguirá estando jerarquicamente debajo de /var, luego /var crece >:-)
Ver un par de párrafos anteriores ;)
El /var puede ser muy grande. Aunque lo gestiones bien, lo repartas, lo archives en tres capas, puede ser enorme. Es a donde van los datos que no son propiedad de un usuario sino de todos, es decir, los datos que se "sirven" desde el servidor.
/var es para ficheros de tamao variable, de ahí el nombre. Pero vuelvo a lo de antes, sí: jerárquicamente /var crece y, jerárquicamente / crece también, pero eso es desde un punto de vista lógico, NO físico ;) Si nos ponemos a mirarlo desde un punto de vista físico (que es el que interesa porque los discos son elementos físicos y no lógicos) lo que crece es el sistema de ficheros y /var /var/cache (por ejemplo) pueden ser dos sistemas de ficheros diferentes luego físicamente, el que crece es /var/cache, pero no /var ;) Lo mismo va para /var/log o /var/mail o /var/lo_que_quieras, si lo diseñas bien, lo diseñarás como sistemas de ficheros diferentes.
Mira, yo en casita tengo ahora mismo 3.4 gigas debajo de /var, según "du -hc /var" Y he tenido más.
Yo, en cambio, tengo ~/downloads/ ocupando muchísimo en el portátil del curro y /home/distros ocupando mucho en mi casa. En el primer caso NO es un sistema de ficheros separado y en el segundo sí, igual que /home/VMs. Otra cosa que hay que tener en cuenta es que en Linux (Unix en general) tienes la gran ventaja de no trabajar con unidades como en MS-Windows (C:, D:, E:, ...). Esto permite que si, por ejemplo te quedas sin espacio en /var/1dir/, puedas o bien enlazar una partición, disco, volumen lógico a /var/1dir/ (una vez me tocó hacer esto porque no se podía para nada ni se podía borrar ni nada de nada) o bien puedes mover datos a un nuevo dispositivo de bloques más grande y montarlo posteriormente. Esto es, claro está, si no has usado volúmenes lógicos ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 23 Apr 2010 00:25:06 +0200, Rafa Grimán escribió:
On Thursday 22 April 2010 17:53 Carlos E. R. wrote
(...)
Siempre y cuando la política de la empresa te deje. Pueden exigirte tener en linea varios gigas de espacio para cada usuario en imap, en plan gmail.
El acrhivado puede está shelved cuando lo sacas de la librería o del jukebox de CD/DVD/BR. Sacar cintas de una librería para backup es bastante normal (hay que evitar que backup y datos estén físicamente próximos). El archivado (a cinta o a CD/DVD/BR) no significa necesarioamente que te lo llevas a otra oficina, a un banco, a un vault o similar, significa que no lo tienes en disco principal. Es decir, puede estar dentro de la librería de cintas.
Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail están archivados en cintas y almacenados allá en Mountain View? >:-)
También hay que tener en cuenta un tipo de archivado "especial" que es lo que se llama copia legal y es básicamente lo que exige la ley en cuanto a determinados datos digitales: que tienes que tener una copia para revisiones legales durante no sé cuánto tiempo. Se tiene que guardar en un medio inalterable (WORM) y tienes que garantizar su lectura durante ese tiempo que exige la ley.
Sí, pero es que no hablamos de "archivar". Archivar implica dar un tratamiento especial a los datos, sacarlos de su ubicación actual y moverlos a otro espacio (físico o lógico) por lo que dejan de estar accesibles en tiempo real para el servidor o el usuario. (...)
El /var puede ser muy grande. Aunque lo gestiones bien, lo repartas, lo archives en tres capas, puede ser enorme. Es a donde van los datos que no son propiedad de un usuario sino de todos, es decir, los datos que se "sirven" desde el servidor.
/var es para ficheros de tamao variable, de ahí el nombre.
Un "tamaño variable" requiere un "espacio variable" y esos datos pueden e estar ahí meses o años antes de pasar a ser archivados >:-)
Pero vuelvo a lo de antes, sí: jerárquicamente /var crece y, jerárquicamente / crece también, pero eso es desde un punto de vista lógico, NO físico ;) Si nos ponemos a mirarlo desde un punto de vista físico (que es el que interesa porque los discos son elementos físicos y no lógicos) lo que crece es el sistema de ficheros y /var /var/cache (por ejemplo) pueden ser dos sistemas de ficheros diferentes luego físicamente, el que crece es /var/cache, pero no /var ;) Lo mismo va para /var/log o /var/mail o /var/lo_que_quieras, si lo diseñas bien, lo diseñarás como sistemas de ficheros diferentes.
Si tienes un disco pequeño, "/var" ni se parte ni se divide. No compensa, al contrario, te penaliza. Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar su tamaño o disminuirlo de forma aleatoria y sin un patrón concreto). Imagina un correo enorme que tenga que estar en la cola dirigido a todos los usuarios del sistema enviado con malas intenciones, e imagina además que por política de empresa todos los mensajes enviados/recibidos se duplican en una cuenta de seguridad... aumentas el espacio requerido en "/ var" de manera exponencial en apenas unos segundos. ¿Y cuándo se eliminan los correos pesados? Pues dependerá de cada usuario. Algunos lo descargaran vía pop, otros lo mantendrán accesible vía imap... y otros no lo bajarán en ¿meses?. O el mismo "zypper" te puede disparar las necesidades de espacio actuales en "/var" al generar archivos de registro de actividad de "no-sé-cuantos" gigas por un error. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Friday 23 April 2010 10:13 Camaleón wrote
El Fri, 23 Apr 2010 00:25:06 +0200, Rafa Grimán escribió:
On Thursday 22 April 2010 17:53 Carlos E. R. wrote
(...)
Siempre y cuando la política de la empresa te deje. Pueden exigirte tener en linea varios gigas de espacio para cada usuario en imap, en plan gmail.
El acrhivado puede está shelved cuando lo sacas de la librería o del jukebox de CD/DVD/BR. Sacar cintas de una librería para backup es bastante normal (hay que evitar que backup y datos estén físicamente próximos). El archivado (a cinta o a CD/DVD/BR) no significa necesarioamente que te lo llevas a otra oficina, a un banco, a un vault o similar, significa que no lo tienes en disco principal. Es decir, puede estar dentro de la librería de cintas.
Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail están archivados en cintas y almacenados allá en Mountain View? >:-)
Te sorprendería saber lo que hay en cinta y el usuario cree que está en disco. Te pongo un ejemplo que es mucho más "delicado": NBA. Está haciendo streaming en Internet de todos sus videos y creeme, la gran mayoría están en cinta. Es cliente nuestro ;) Otra cosa, no confundas cosas. Yo no he dicho que tenga que estar TODO en cinta, he dicho cosas como (copio y pego): "2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos" "Los ficheros más usados, se encuentran en los discos SAS, los menos usados en SATA y los que están llenos de polvo en cinta." "Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar." Es decir, lo que se archiva o lo que se migra (en el caso de HSM) son datos antiguos. Obviamente, los correos de ayer y de hoy no se migran. ¿Quién define lo que es antiguo? Como siempre, el jefe ;) Como Admin, debes opinar y presentar un estudio de uso del correo (o cualquier otro dato). Yo, como fabricante o integrador no te puedo decir cada cuánto tienes que migrar o archivar los datos, ATEMPO tampoco, IBM tampoco, EMC tampoco, ... Eso lo tienes que establecer tu como admin de tu empresa. Como integrador y fabricnate lo que sí es hecho es ayudar al cliente y asesorarle y formarle en el uso de la herramienta de forma que si quiere cambiar sus políticas, lo pueda hacer sin mi. De hecho, los 3 - 4 primeros meses la gente se queja y andas experimentando hasta que consigues afinar las reglas. Pero una vez que tienes las reglas "en su sitio", la cosa funciona. Claro está que puedes contratar a una empresa para que te haga ese estudio ... pero vas a tener que pagar la consultoría (y el SW que quieran instalar para monitorizar el comportamiento de los usuarios y el flujo de trabajo). También es cierto que tus políticas no le valen a Google ni a la gestoría de la esquina ni a la NBA, cada caso es un mundo. Por eso, lo tienen que decidir el cliente final. En cuanto a Google, creeme, lo tienen todo muy bien estudiado y no me extrañaría que tuvieran en cinta mucha más info de la que creemos ;) No sólo Google sino otros como FaceBook o NYSE o cualquier otro grande.
También hay que tener en cuenta un tipo de archivado "especial" que es lo que se llama copia legal y es básicamente lo que exige la ley en cuanto a determinados datos digitales: que tienes que tener una copia para revisiones legales durante no sé cuánto tiempo. Se tiene que guardar en un medio inalterable (WORM) y tienes que garantizar su lectura durante ese tiempo que exige la ley.
Sí, pero es que no hablamos de "archivar". Archivar implica dar un tratamiento especial a los datos, sacarlos de su ubicación actual y moverlos a otro espacio (físico o lógico) por lo que dejan de estar accesibles en tiempo real para el servidor o el usuario.
Volvemos a lo de antes, se supone que has hecho un estudio sobre qué datos y cuándo se pueden migrar porque no hace falta tiempo real. Este es el caso de correo-e, documentos ofimáticos, imágenes, ... En el caso de audio y/o vídeo que sí puedes necesitar tiempo real (el streaming de YouTube, por ejemplo, no es tiempo real ni lo es ningún streaming basado en Flash), lo que se hace es lo que he comentado en un correo anterior (copio y pego): " - dejar los primeros segundos en el nivel 1 y el resto migrarlo - migrar ciertas partes, por ejemplo, del minuto 1 al 7, del 8 al 9 los mirga a nivel 2 dejando el resto de minutos en nivel 1. Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar sino que lo vé inmediatamente y cree que está todo on-line."
El /var puede ser muy grande. Aunque lo gestiones bien, lo repartas, lo archives en tres capas, puede ser enorme. Es a donde van los datos que no son propiedad de un usuario sino de todos, es decir, los datos que se "sirven" desde el servidor.
/var es para ficheros de tamao variable, de ahí el nombre.
Un "tamaño variable" requiere un "espacio variable" y esos datos pueden e estar ahí meses o años antes de pasar a ser archivados >:-)
Efectivamente y esa variación de tamaño luego se refleja en la cantidad "variable" de dinero que quieras pagar: - disco -> más caro + más consumo + más calor - cinta -> más barato + menos consumo + menos calor Oye, por mi encantado que NO quieras archivar y ójala todos los clientes pensaran así -> vendería más disco y me haría rico. Pero la realidad es otra: "¿por qué pagar más por mantener un dato on-line cuando NO es necesario que esté on-ĺine?" Y creeme, que si el jefe y el de contabilidad/compras/financiero oyen "pagar más" o "pagar menos" ... la cosa cambia.
Pero vuelvo a lo de antes, sí: jerárquicamente /var crece y, jerárquicamente / crece también, pero eso es desde un punto de vista lógico, NO físico ;) Si nos ponemos a mirarlo desde un punto de vista físico (que es el que interesa porque los discos son elementos físicos y no lógicos) lo que crece es el sistema de ficheros y /var /var/cache (por ejemplo) pueden ser dos sistemas de ficheros diferentes luego físicamente, el que crece es /var/cache, pero no /var ;) Lo mismo va para /var/log o /var/mail o /var/lo_que_quieras, si lo diseñas bien, lo diseñarás como sistemas de ficheros diferentes.
Si tienes un disco pequeño, "/var" ni se parte ni se divide. No compensa, al contrario, te penaliza.
Si tienes un disco físico pequeño en *nix, hacerlo crecer es muy sencillo: compras un disco nuevo y lo montas bajo /var/disco_nuevo ;)
Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar su tamaño o disminuirlo de forma aleatoria y sin un patrón concreto).
Por eso mismo existen: - gestores de volúmenes - sw de HSM - sw de archivado - dedupe
Imagina un correo enorme que tenga que estar en la cola dirigido a todos los usuarios del sistema enviado con malas intenciones,
Para eso se establecen límites en el tamaño del correo, entre otros límites ;) Si no estableces límites: mal hecho. Ya, ya sé que el usuario se queja si le pones límites. Tuve un amigo trabajando en "Infobirria" y le llamo un lciente indignado porque "el correo no funciona". El cliente quería enviar una imagen iso por correo. Sí, quería envíar los 670 MBytes de un CD a un colega. Pues qué quieres que te diga ... que se queje todo lo que quiera, hay unos límites en el correo y en las autopistas y en la tarjeta de crédito y en lo que puedes comer/beber de una sentada y en todo en esta vida.
e imagina además que por política de empresa todos los mensajes enviados/recibidos se duplican en una cuenta de seguridad... aumentas el espacio requerido en "/ var" de manera exponencial en apenas unos segundos.
Tu lo has dicho: es una COPIA, luego no es necesaria on-line porque tienes el original on-line. Es un ejemplo de lo que en un correo anterior llamaba (o llaman algunos clientes/empresas) copia legal. Esa copia puede estar perfectamente en una librería de cintas, bien sea con o sin VTL por en medio para darle mayor agilidad/velocidad al proceso o se hace todas las noches o la política que creas conveniente, pero es lo que tu misma has dicho: una copia.
¿Y cuándo se eliminan los correos pesados? Pues dependerá de cada usuario. Algunos lo descargaran vía pop, otros lo mantendrán accesible vía imap... y otros no lo bajarán en ¿meses?.
Pero ahí ya interviene la política de empresa. si la empresa dice que se hace así, así y así. Pues es como hay que hacerlo. Los recursos son de la empresa, nos guste o no y es la empresa la que establece las normas. Obviamente, si tu como Admin le consigues explicar bien las cosas al jefe ... se harán "bien". Si tu, como Admin, rechazas una tecnología porque sí ... a lo mejor te estás perdiendo una cosa que te ahorraría mucha pasta y que podrías invertir en cosas que necesitas: formación, renovación de equipos, ...
O el mismo "zypper" te puede disparar las necesidades de espacio actuales en "/var" al generar archivos de registro de actividad de "no-sé-cuantos" gigas por un error.
Ahí hay otra tecnología que se llama thin provisioning u oversubscription. También hay una cosa que se llama previsión, como Admin tienes que preveer la cantidad de un recurso que vas a necesitar. Obviamente es IMPOSIBLE acertar con las predicciones, pero tienes una idea. En HPC (sea científico, media, financiero, ...) el volumen de datos que se maneja es algo inhumano y las previsiones a 3 años sabes a ciencia cierta que el 1er año te las vas a fundir, peor aún así ... se hacen estimaciones y previsiones para no quedarte de pronto sin espacio. ¿Qué ocurre cuando esta gente se queda de pronto sin espacio? Muy sencillo: 1.- monitorizan todo mucho para que esto casi no ocurra 2. -tienen SW de archivado 3.- tienen SW de HSM 4.- tienen SW de dedupe 5.- tienen políticas a medida en función de sus flujos de trabajo Siendo el 5 punto el más importante. Ya sé que me vas a decir que tu no manejas sus presupuestos, pero no tiene nada que ver porque su presupuesto es 500% mayor que el tuyo, pero sus necesidades son 5000% mayores que las tuyas por lo que salen ellos perdiendo ;) Además de eso, piensa que: - a lo mejor tu no necesitas HSM: ya te has quitado un gasto que ellos sí tienen - a lo mejor tu puedes funcionar perfectamente con un sw de backup* FLOSS: te has ahorrado las licencias que ellos tienen que pagar porque no hay soluciones FLOSS que les valga * o cualquier otro sw que tu no licencias y ellos sí: servidores de ficheros, servidor de correo, ... Te vuelvo a repetir: no te estoy inentando convencer de que uses o no una tecnología (sea de gestión de almacenamiento, como es este caso) o sea de monitorización de cámaras IP. Yo te comento lo que hay, lo que se usa, en qué casos, ... que a ti te guste o no, que te convenzca, que te parezca bueno o no, ... Oye, ya es cosa tuya: yo sólo intento ayudar porque he visto que en casos similares ... sí ha funcionado ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 23 Apr 2010 11:10:23 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 10:13 Camaleón wrote
Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail están archivados en cintas y almacenados allá en Mountain View? >:-)
Te sorprendería saber lo que hay en cinta y el usuario cree que está en disco. Te pongo un ejemplo que es mucho más "delicado": NBA. Está haciendo streaming en Internet de todos sus videos y creeme, la gran mayoría están en cinta. Es cliente nuestro ;)
La NBA no usa un servicio como Gmail :-) A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual, el volumen de datos que tiene que manejar la NBA no es el volumen de datos que tiene que manejar cualquier empresa ni las estrategias que tienen definidas, tampoco se ajustan a una empresa media.
Otra cosa, no confundas cosas. Yo no he dicho que tenga que estar TODO en cinta, he dicho cosas como (copio y pego):
"2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos"
¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a los correos que tengo desde de la lista el año 2.003 es instantáneo, dudo mucho que los tengan almacenados como archivo.
"Los ficheros más usados, se encuentran en los discos SAS, los menos usados en SATA y los que están llenos de polvo en cinta."
"Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar."
"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa archiva en un día otra no lo llega a archivar en 5 años (debido a la diferencia entre la cantidad de datos que genera una y otra). (...)
También es cierto que tus políticas no le valen a Google ni a la gestoría de la esquina ni a la NBA, cada caso es un mundo. Por eso, lo tienen que decidir el cliente final.
Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho ;-)
En cuanto a Google, creeme, lo tienen todo muy bien estudiado y no me extrañaría que tuvieran en cinta mucha más info de la que creemos ;) No sólo Google sino otros como FaceBook o NYSE o cualquier otro grande.
Demasiado rápido va como para que esté archivado, no me convence.
Sí, pero es que no hablamos de "archivar". Archivar implica dar un tratamiento especial a los datos, sacarlos de su ubicación actual y moverlos a otro espacio (físico o lógico) por lo que dejan de estar accesibles en tiempo real para el servidor o el usuario.
Volvemos a lo de antes, se supone que has hecho un estudio sobre qué datos y cuándo se pueden migrar porque no hace falta tiempo real. Este es el caso de correo-e, documentos ofimáticos, imágenes, ...
Pero Rafa, a ver... cómo te lo diría. Mi "/vares" crecen y necesito tener espacio disponible para que puedan aumentar hasta lo que quieran (hasta lo que le permita el disco) porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas. Con 1.2 TiB para espacio compartido de archivos y backup de momento nos sobra :-P
/var es para ficheros de tamao variable, de ahí el nombre.
Un "tamaño variable" requiere un "espacio variable" y esos datos pueden e estar ahí meses o años antes de pasar a ser archivados >:-)
Efectivamente y esa variación de tamaño luego se refleja en la cantidad "variable" de dinero que quieras pagar: - disco -> más caro + más consumo + más calor - cinta -> más barato + menos consumo + menos calor
Pero es que necesito que estén en disco y accesibles, no en cinta y archivados.
Oye, por mi encantado que NO quieras archivar y ójala todos los clientes pensaran así -> vendería más disco y me haría rico. Pero la realidad es otra:
"¿por qué pagar más por mantener un dato on-line cuando NO es necesario que esté on-ĺine?"
Y creeme, que si el jefe y el de contabilidad/compras/financiero oyen "pagar más" o "pagar menos" ... la cosa cambia.
Porque cuesta (tiempo, dinero, mantenimiento) más llevarte ese dato offline que mantenerlo online. Y porque en el caso de los correos, necesitas tenerlos en línea, disponibles, frescos.
Si tienes un disco pequeño, "/var" ni se parte ni se divide. No compensa, al contrario, te penaliza.
Si tienes un disco físico pequeño en *nix, hacerlo crecer es muy sencillo: compras un disco nuevo y lo montas bajo /var/disco_nuevo ;)
Eso será si te puedes permitir el lujo de comprar un disco nuevo y de más capacidad (hay quien no puede ni eso) y para los afortunados que pueden comprarlo y ampliar el espacio, tienen además que tener una configuración que admita la gestión de volumen dinámicos (el LVM que estábamos comentando) y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar su tamaño o disminuirlo de forma aleatoria y sin un patrón concreto).
Por eso mismo existen: - gestores de volúmenes - sw de HSM - sw de archivado - dedupe
Inviable en muchas empresas.
Imagina un correo enorme que tenga que estar en la cola dirigido a todos los usuarios del sistema enviado con malas intenciones,
Para eso se establecen límites en el tamaño del correo, entre otros límites ;) Si no estableces límites: mal hecho.
No, no puedes. Eso no depende de ti, y nosotros podemos recibir planos completos en AutoCAD por correo electrónico (no preguntes...). Tengo que relajar esas normas o podemos perder mucho, no sólo tiempo sino dinero. (...)
e imagina además que por política de empresa todos los mensajes enviados/recibidos se duplican en una cuenta de seguridad... aumentas el espacio requerido en "/ var" de manera exponencial en apenas unos segundos.
Tu lo has dicho: es una COPIA, luego no es necesaria on-line porque tienes el original on-line.
No se trata de que esté o no archivada, se trata de que te ocupa espacio en disco... hasta que llegue a su destino. Y su destino puede ser "/var/ mail", donde la persona que se encargue de consultar esos correos lo haga mediante IMAP y ahí se quedan los correos hasta que al año siguiente se archivan.
Es un ejemplo de lo que en un correo anterior llamaba (o llaman algunos clientes/empresas) copia legal.
Esa copia puede estar perfectamente en una librería de cintas, bien sea con o sin VTL por en medio para darle mayor agilidad/velocidad al proceso o se hace todas las noches o la política que creas conveniente, pero es lo que tu misma has dicho: una copia.
Pero es que no hay un "caso de uso" único. Cada empresa o cada usuario tiene establecido un método de trabajo distinto, acorde a sus necesidades.
¿Y cuándo se eliminan los correos pesados? Pues dependerá de cada usuario. Algunos lo descargaran vía pop, otros lo mantendrán accesible vía imap... y otros no lo bajarán en ¿meses?.
Pero ahí ya interviene la política de empresa. si la empresa dice que se hace así, así y así. Pues es como hay que hacerlo. Los recursos son de la empresa, nos guste o no y es la empresa la que establece las normas. Obviamente, si tu como Admin le consigues explicar bien las cosas al jefe ... se harán "bien".
Si tu, como Admin, rechazas una tecnología porque sí ... a lo mejor te estás perdiendo una cosa que te ahorraría mucha pasta y que podrías invertir en cosas que necesitas: formación, renovación de equipos, ...
Rafa, hay muchas formas de hacer las cosas bien. Ya me gustaría a mí poder tener los servidores web (o los de correo) en HA, o al menos re- duplicados. No puedo. O aumentar el almacenamiento de la red local. No puedo. Tengo que trabajar con lo que hay y rentabilizar no sólo en material sino en tiempo >:-)
O el mismo "zypper" te puede disparar las necesidades de espacio actuales en "/var" al generar archivos de registro de actividad de "no-sé-cuantos" gigas por un error.
Ahí hay otra tecnología que se llama thin provisioning u oversubscription. También hay una cosa que se llama previsión, como Admin tienes que preveer la cantidad de un recurso que vas a necesitar. Obviamente es IMPOSIBLE acertar con las predicciones, pero tienes una idea.
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P (...)
Te vuelvo a repetir: no te estoy inentando convencer de que uses o no una tecnología (sea de gestión de almacenamiento, como es este caso) o sea de monitorización de cámaras IP. Yo te comento lo que hay, lo que se usa, en qué casos, ... que a ti te guste o no, que te convenzca, que te parezca bueno o no, ... Oye, ya es cosa tuya: yo sólo intento ayudar porque he visto que en casos similares ... sí ha funcionado ;)
Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
El Fri, 23 Apr 2010 11:10:23 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 10:13 Camaleón wrote
Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail están archivados en cintas y almacenados allá en Mountain View? >:-)
Te sorprendería saber lo que hay en cinta y el usuario cree que está en disco. Te pongo un ejemplo que es mucho más "delicado": NBA. Está haciendo streaming en Internet de todos sus videos y creeme, la gran mayoría están en cinta. Es cliente nuestro ;)
La NBA no usa un servicio como Gmail :-)
A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual, el volumen de datos que tiene que manejar la NBA no es el volumen de datos que tiene que manejar cualquier empresa ni las estrategias que tienen definidas, tampoco se ajustan a una empresa media.
Otra cosa, no confundas cosas. Yo no he dicho que tenga que estar TODO en cinta, he dicho cosas como (copio y pego):
"2.- como admin, estableces reglas de migración que auto- máticamente t emigran los correos más antiguos"
¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a los correos que tengo desde de la lista el año 2.003 es instantáneo, dudo mucho que los tengan almacenados como archivo.
"Los ficheros más usados, se encuentran en los discos SAS, los menos usados en SATA y los que están llenos de polvo en cinta."
"Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos y se pueden archivar."
"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa archiva en un día otra no lo llega a archivar en 5 años (debido a la diferencia entre la cantidad de datos que genera una y otra).
(...)
También es cierto que tus políticas no le valen a Google ni a la gestoría de la esquina ni a la NBA, cada caso es un mundo. Por eso, lo tienen que decidir el cliente final.
Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho ;-)
En cuanto a Google, creeme, lo tienen todo muy bien estudiado y no me extrañaría que tuvieran en cinta mucha más info de la que creemos ;) No sólo Google sino otros como FaceBook o NYSE o cualquier otro grande.
Demasiado rápido va como para que esté archivado, no me convence.
Sí, pero es que no hablamos de "archivar". Archivar implica dar un tratamiento especial a los datos, sacarlos de su ubicación actual y moverlos a otro espacio (físico o lógico) por lo que dejan de estar accesibles en tiempo real para el servidor o el usuario.
Volvemos a lo de antes, se supone que has hecho un estudio sobre qué datos y cuándo se pueden migrar porque no hace falta tiempo real. Este es el caso de correo-e, documentos ofimáticos, imágenes, ...
Pero Rafa, a ver... cómo te lo diría. Mi "/vares" crecen y necesito tener espacio disponible para que puedan aumentar hasta lo que quieran (hasta lo que le permita el disco) porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas. Con 1.2 TiB para espacio compartido de archivos y backup de momento nos sobra :-P
/var es para ficheros de tamao variable, de ahí el nombre. Un "tamaño variable" requiere un "espacio variable" y esos datos pueden e estar ahí meses o años antes de pasar a ser archivados >:-)
Efectivamente y esa variación de tamaño luego se refleja en la cantidad "variable" de dinero que quieras pagar: - disco -> más caro + más consumo + más calor - cinta -> más barato + menos consumo + menos calor
Pero es que necesito que estén en disco y accesibles, no en cinta y archivados.
Oye, por mi encantado que NO quieras archivar y ójala todos los clientes pensaran así -> vendería más disco y me haría rico. Pero la realidad es otra:
"¿por qué pagar más por mantener un dato on-line cuando NO es necesario que esté on-ĺine?"
Y creeme, que si el jefe y el de contabilidad/compras/financiero oyen "pagar más" o "pagar menos" ... la cosa cambia.
Porque cuesta (tiempo, dinero, mantenimiento) más llevarte ese dato offline que mantenerlo online. Y porque en el caso de los correos, necesitas tenerlos en línea, disponibles, frescos.
Si tienes un disco pequeño, "/var" ni se parte ni se divide. No compensa, al contrario, te penaliza.
Si tienes un disco físico pequeño en *nix, hacerlo crecer es muy sencillo: compras un disco nuevo y lo montas bajo /var/disco_nuevo ;)
Eso será si te puedes permitir el lujo de comprar un disco nuevo y de más capacidad (hay quien no puede ni eso) y para los afortunados que pueden comprarlo y ampliar el espacio, tienen además que tener una configuración que admita la gestión de volumen dinámicos (el LVM que estábamos comentando) y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar su tamaño o disminuirlo de forma aleatoria y sin un patrón concreto).
Por eso mismo existen: - gestores de volúmenes - sw de HSM - sw de archivado - dedupe
Inviable en muchas empresas.
Imagina un correo enorme que tenga que estar en la cola dirigido a todos los usuarios del sistema enviado con malas intenciones,
Para eso se establecen límites en el tamaño del correo, entre otros límites ;) Si no estableces límites: mal hecho.
No, no puedes. Eso no depende de ti, y nosotros podemos recibir planos completos en AutoCAD por correo electrónico (no preguntes...). Tengo que relajar esas normas o podemos perder mucho, no sólo tiempo sino dinero.
(...)
e imagina además que por política de empresa todos los mensajes enviados/recibidos se duplican en una cuenta de seguridad... aumentas el espacio requerido en "/ var" de manera exponencial en apenas unos segundos.
Tu lo has dicho: es una COPIA, luego no es necesaria on-line porque tienes el original on-line.
No se trata de que esté o no archivada, se trata de que te ocupa espacio en disco... hasta que llegue a su destino. Y su destino puede ser "/var/ mail", donde la persona que se encargue de consultar esos correos lo haga mediante IMAP y ahí se quedan los correos hasta que al año siguiente se archivan.
Es un ejemplo de lo que en un correo anterior llamaba (o llaman algunos clientes/empresas) copia legal.
Esa copia puede estar perfectamente en una librería de cintas, bien sea con o sin VTL por en medio para darle mayor agilidad/velocidad al proceso o se hace todas las noches o la política que creas conveniente, pero es lo que tu misma has dicho: una copia.
Pero es que no hay un "caso de uso" único. Cada empresa o cada usuario tiene establecido un método de trabajo distinto, acorde a sus necesidades.
¿Y cuándo se eliminan los correos pesados? Pues dependerá de cada usuario. Algunos lo descargaran vía pop, otros lo mantendrán accesible vía imap... y otros no lo bajarán en ¿meses?.
Pero ahí ya interviene la política de empresa. si la empresa dice que se hace así, así y así. Pues es como hay que hacerlo. Los recursos son de la empresa, nos guste o no y es la empresa la que establece las normas. Obviamente, si tu como Admin le consigues explicar bien las cosas al jefe ... se harán "bien".
Si tu, como Admin, rechazas una tecnología porque sí ... a lo mejor te estás perdiendo una cosa que te ahorraría mucha pasta y que podrías invertir en cosas que necesitas: formación, renovación de equipos, ...
Rafa, hay muchas formas de hacer las cosas bien. Ya me gustaría a mí poder tener los servidores web (o los de correo) en HA, o al menos re- duplicados. No puedo. O aumentar el almacenamiento de la red local. No puedo. Tengo que trabajar con lo que hay y rentabilizar no sólo en material sino en tiempo >:-)
O el mismo "zypper" te puede disparar las necesidades de espacio actuales en "/var" al generar archivos de registro de actividad de "no-sé-cuantos" gigas por un error.
Ahí hay otra tecnología que se llama thin provisioning u oversubscription. También hay una cosa que se llama previsión, como Admin tienes que preveer la cantidad de un recurso que vas a necesitar. Obviamente es IMPOSIBLE acertar con las predicciones, pero tienes una idea.
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
(...)
Te vuelvo a repetir: no te estoy inentando convencer de que uses o no una tecnología (sea de gestión de almacenamiento, como es este caso) o sea de monitorización de cámaras IP. Yo te comento lo que hay, lo que se usa, en qué casos, ... que a ti te guste o no, que te convenzca, que te parezca bueno o no, ... Oye, ya es cosa tuya: yo sólo intento ayudar porque he visto que en casos similares ... sí ha funcionado ;)
Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-)
Saludos,
Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a pagar. Ejemplo: - 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas permitir. - Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web, etc. Metes todo el dinero que puedas en el hardware, más la electrónica. A partir de aquí puedes usar buen software libre para montar dos servidores de storage en HA y los demás servidores dando servicio y te olvidas de esos problemas que se comentan de espacio en /var. Y por cierto, todo y cuando y digo todo es todo, lo que se almacena en /var es fácilmente movible a cualquier otro espacio de disco: bases de datos, spool del mta, etc. Todo. A mí no se me ocurre ningún caso en el que no se pueda hacer, aunque no digo que no lo haya pero no se me ocurre. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 23 Apr 2010 12:35:35 +0200, carlopmart escribió: Puedes recortar el correo :-)
Camaleón wrote:
(...)
Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-)
Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a pagar. Ejemplo:
- 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas permitir. - Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web, etc.
Y ahora multiplica eso x2 para el archivado por capas que sugiere Rafa porque además de HA tienes que tenerlo todo almacenadito y con su backup correspondiente >:-)
Metes todo el dinero que puedas en el hardware, más la electrónica. A partir de aquí puedes usar buen software libre para montar dos servidores de storage en HA y los demás servidores dando servicio y te olvidas de esos problemas que se comentan de espacio en /var.
Ains, sí, eso no estaría mal. No siempre se empieza desde cero ni con todo el material que a uno le gustaría...
Y por cierto, todo y cuando y digo todo es todo, lo que se almacena en /var es fácilmente movible a cualquier otro espacio de disco: bases de datos, spool del mta, etc. Todo. A mí no se me ocurre ningún caso en el que no se pueda hacer, aunque no digo que no lo haya pero no se me ocurre.
Nadie dice que no lo puedas mover, sólo que las colas no mantienen un tamaño predecible ni fijo. Y las colas suelen estar en /var (configuraciones personales/concretas aparte). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a pagar. Ejemplo:
- 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas permitir. - Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web, etc.
Y ahora multiplica eso x2 para el archivado por capas que sugiere Rafa porque además de HA tienes que tenerlo todo almacenadito y con su backup correspondiente >:-)
A ver el ejemplo de Rafa que te pone naturalmente es para gran empresa. Yo te pongo un ejemplo más sencillo para empresas pequeñas y medianas.
Metes todo el dinero que puedas en el hardware, más la electrónica. A partir de aquí puedes usar buen software libre para montar dos servidores de storage en HA y los demás servidores dando servicio y te olvidas de esos problemas que se comentan de espacio en /var.
Ains, sí, eso no estaría mal. No siempre se empieza desde cero ni con todo el material que a uno le gustaría...
Cierto, pero puedes planificar migraciones, ¿no?. A fin de cuentas las necesidades de una empresa no són estáticas a lo largo de su existencia, igual que no lo son las informáticas.
Y por cierto, todo y cuando y digo todo es todo, lo que se almacena en /var es fácilmente movible a cualquier otro espacio de disco: bases de datos, spool del mta, etc. Todo. A mí no se me ocurre ningún caso en el que no se pueda hacer, aunque no digo que no lo haya pero no se me ocurre.
Nadie dice que no lo puedas mover, sólo que las colas no mantienen un tamaño predecible ni fijo. Y las colas suelen estar en /var (configuraciones personales/concretas aparte).
Saludos,
Pero lo que te vengo a decir es que pueden no estarlo si el administrador no quiere. Y es verdad uno/a no puede predecir lo que puede crecer cierto filesystem, pero para eso tienes a "dedup" y te evitas esos problemas. Y dedup en ZFS es free ... Info para las personas que necesiten montar un almacenamiento duradero y con tecnología HA y dedup: http://eonstorage.blogspot.com/ http://www.nexentastor.org/projects/site/wiki/CommunityEdition http://www.freenas.org/ http://www.openfiler.com/ Y algunos ejemplos prácticos en entornos de producción reales: http://blog.laspina.ca/ubiquitous/running-zfs-over-nfs-as-a-vmware-store http://blog.laspina.ca/ubiquitous/controlling-snapshot-noise http://blogs.sun.com/bonwick/entry/zfs_dedup http://blogs.sun.com/jsavit/entry/deduplication_now_in_zfs http://cuddletech.com/blog/pivot/entry.php?id=1092 Si ya sé que son ejemplos para opensolaris (la mejor plataforma de soft libre para almacenamiento según mi opinión), pero para linux teneis drbd o incluso glusterfs: http://www.gluster.org/, en mi opinión mejor que drbd para hacer réplicas entre servidores y tener un HA de storage aunque requiere algo más de infraestructura. Por cierto, la tecnología dedup creo que no existe todavía para los filesystems soportados por linux. Si me equivoco que alguien me corrija. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 23 Apr 2010 13:16:30 +0200, carlopmart escribió:
Camaleón wrote:
Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a pagar. Ejemplo:
- 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas permitir. - Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web, etc.
Y ahora multiplica eso x2 para el archivado por capas que sugiere Rafa porque además de HA tienes que tenerlo todo almacenadito y con su backup correspondiente >:-)
A ver el ejemplo de Rafa que te pone naturalmente es para gran empresa. Yo te pongo un ejemplo más sencillo para empresas pequeñas y medianas.
¿Empresas pequeñas y medianas con servidores en HA y 12 equipos dedicados con copias y almacenamiento en cinta? ¿Dónde? ¿En Iowa o en Valdemorillo? :-)
Ains, sí, eso no estaría mal. No siempre se empieza desde cero ni con todo el material que a uno le gustaría...
Cierto, pero puedes planificar migraciones, ¿no?. A fin de cuentas las necesidades de una empresa no són estáticas a lo largo de su existencia, igual que no lo son las informáticas.
Por planificar que no quede. Otra cosa es que se llegue a ejecutar o que tengas que cambiar los planes. Las necesidades de una empresa cambian muy rápido.
Nadie dice que no lo puedas mover, sólo que las colas no mantienen un tamaño predecible ni fijo. Y las colas suelen estar en /var (configuraciones personales/concretas aparte).
Pero lo que te vengo a decir es que pueden no estarlo si el administrador no quiere.
O está sujeto al FHS, por ejemplo. No es mi caso, todo sea dicho.
Y es verdad uno/a no puede predecir lo que puede crecer cierto filesystem, pero para eso tienes a "dedup" y te evitas esos problemas.
Y dedup en ZFS es free ...
Alguien dijo por aquí una vez que el ZFS era más peligroso que un "nublao" (si perdías datos, los perdías todos)... ¿o me estoy inventando cosas? O:-)
Info para las personas que necesiten montar un almacenamiento duradero y con tecnología HA y dedup:
http://eonstorage.blogspot.com/ http://www.nexentastor.org/projects/site/wiki/CommunityEdition http://www.freenas.org/ http://www.openfiler.com/
Y algunos ejemplos prácticos en entornos de producción reales:
http://blog.laspina.ca/ubiquitous/running-zfs-over-nfs-as-a-vmware-store http://blog.laspina.ca/ubiquitous/controlling-snapshot-noise http://blogs.sun.com/bonwick/entry/zfs_dedup http://blogs.sun.com/jsavit/entry/deduplication_now_in_zfs http://cuddletech.com/blog/pivot/entry.php?id=1092
Los miro más tarde...
Si ya sé que son ejemplos para opensolaris (la mejor plataforma de soft libre para almacenamiento según mi opinión), pero para linux teneis drbd o incluso glusterfs: http://www.gluster.org/, en mi opinión mejor que drbd para hacer réplicas entre servidores y tener un HA de storage aunque requiere algo más de infraestructura.
Hala, todos para Solaris, venga :-P
Por cierto, la tecnología dedup creo que no existe todavía para los filesystems soportados por linux. Si me equivoco que alguien me corrija.
No sabía que dependiera tanto del sistema de archivos :-? Deduping Storage Deduplication http://www.linux-mag.com/cache/7535/1.html Parece que hay implementaciones aparte: http://www.opendedup.org/ Huys, requiere java... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Friday 23 April 2010 13:36 Camaleón wrote
El Fri, 23 Apr 2010 13:16:30 +0200, carlopmart escribió:
Camaleón wrote:
Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a
pagar. Ejemplo: - 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas permitir. - Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web, etc.
Y ahora multiplica eso x2 para el archivado por capas que sugiere Rafa porque además de HA tienes que tenerlo todo almacenadito y con su backup correspondiente >:-)
A ver el ejemplo de Rafa que te pone naturalmente es para gran empresa. Yo te pongo un ejemplo más sencillo para empresas pequeñas y medianas.
¿Empresas pequeñas y medianas con servidores en HA y 12 equipos dedicados con copias y almacenamiento en cinta? ¿Dónde? ¿En Iowa o en Valdemorillo? :-)
¿Quién ha dicho que hace falta tener 12 equipos dedicados a copias y almacenamiento en cinta? No exageres ni tergiverses. Yo he explicado una tecnología, cómo la implementas es cosa tuya. Hoy en día con la potneca del hardware, con 2 servidores puedes meter todo el correo, la web, el FTP, el proxy, la BBDD, el archivado y el backup. Opcionalmente puedes usar una librería de cintas si quieres archivar o hacer backups a cinta o bien puedes pillarte una cabina de discos JBOD (no hace falta ni que tenga controladora RAID) en la que tengas datos, archivo, backup y hasta las fotos del bautizo del sobrino ;) Ni switches FC, ni HBAs ni nada caro. Es más, como me aprietes más, te lo montas con iSCSI y equipos antiguos. Lo que sí recomiendo es que el backup y la copia legal o archivado legal o como lo quieras llamar esté físicamente en otro medio y en otro lugar. [...]
Y es verdad uno/a no puede predecir lo que puede crecer cierto filesystem, pero para eso tienes a "dedup" y te evitas esos problemas.
Y dedup en ZFS es free ...
Alguien dijo por aquí una vez que el ZFS era más peligroso que un "nublao" (si perdías datos, los perdías todos)... ¿o me estoy inventando cosas? O:-)
No t einvemtas nada, lo puedes encontrar en Internet. Pero eso no es razón para no usarlo. Si mal no recuerdo, a Carlos (Robinson) no hay sistema de ficheros que se le resista ;) [...]
Por cierto, la tecnología dedup creo que no existe todavía para los filesystems soportados por linux. Si me equivoco que alguien me corrija.
No sabía que dependiera tanto del sistema de archivos :-?
Deduping Storage Deduplication http://www.linux-mag.com/cache/7535/1.html
Parece que hay implementaciones aparte:
Huys, requiere java...
Es loque comentaba en un correo anterior, soluciones dedpue, HSM, archivado, ... FLOSS hay muy poco y lo poco que hay está un poco verde, le faltan cosas, ... Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
¿Empresas pequeñas y medianas con servidores en HA y 12 equipos dedicados con copias y almacenamiento en cinta? ¿Dónde? ¿En Iowa o en Valdemorillo? :-)
¿Quién ha dicho que hace falta tener 12 equipos dedicados a copias y almacenamiento en cinta? No exageres ni tergiverses. Yo he explicado una tecnología, cómo la implementas es cosa tuya.
Hoy en día con la potneca del hardware, con 2 servidores puedes meter todo el correo, la web, el FTP, el proxy, la BBDD, el archivado y el backup. Opcionalmente puedes usar una librería de cintas si quieres archivar o hacer backups a cinta o bien puedes pillarte una cabina de discos JBOD (no hace falta ni que tenga controladora RAID) en la que tengas datos, archivo, backup y hasta las fotos del bautizo del sobrino ;)
Ni switches FC, ni HBAs ni nada caro. Es más, como me aprietes más, te lo montas con iSCSI y equipos antiguos.
Lo que sí recomiendo es que el backup y la copia legal o archivado legal o como lo quieras llamar esté físicamente en otro medio y en otro lugar.
[...]
Corroboro esto. ¿Quien ha hablado de 12 servidores? He puesto el ejemplo de entre 4 y 6 servidores ... no más. Y eso cubre a muchas empresas (por no decir a todas las pequeñas y muchas medianas) si se dimensiona todo de la forma correcta.
Alguien dijo por aquí una vez que el ZFS era más peligroso que un "nublao" (si perdías datos, los perdías todos)... ¿o me estoy inventando cosas? O:-)
No t einvemtas nada, lo puedes encontrar en Internet. Pero eso no es razón para no usarlo. Si mal no recuerdo, a Carlos (Robinson) no hay sistema de ficheros que se le resista ;)
[...]
Cierto, pero piensa una cosa: si tienes HA en storage, eso deja de ser un problema. Pero también digo más: hay que ser muy torpe para llegar a ese extremo de perderlo todo. Puede ocurrir una vez de cada muchas muchas, si sabes lo que haces ...
Por cierto, la tecnología dedup creo que no existe todavía para los filesystems soportados por linux. Si me equivoco que alguien me corrija. No sabía que dependiera tanto del sistema de archivos :-?
Deduping Storage Deduplication http://www.linux-mag.com/cache/7535/1.html
Parece que hay implementaciones aparte:
Huys, requiere java...
Es loque comentaba en un correo anterior, soluciones dedpue, HSM, archivado, ... FLOSS hay muy poco y lo poco que hay está un poco verde, le faltan cosas, ...
No digo que dedup sea dependiente de filesystem, pero si el filesystem te lo lleva integradito mejor ¿no?. En FLOSS que yo sepa solo ZFS y ojo está probadísimo en entornos de producción ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón wrote:
Hala, todos para Solaris, venga :-P
Yo no he dicho eso. Es más te he puesto ejemplos para linux: drbd y glusterfs ... -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Friday 23 April 2010 13:01 Camaleón wrote
El Fri, 23 Apr 2010 12:35:35 +0200, carlopmart escribió:
Puedes recortar el correo :-)
Camaleón wrote: (...)
Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-)
Pero es que una empresa media (y hasta pequeña) puede hacerse con una infraestructura de HA 99,999% operativa. No es tan alto el precio a
pagar. Ejemplo: - 2 servidores con 4/8GB de RAM y el máximo espacio de disco que te puedas permitir. - Entre 2 y 4 servidores más dando todos los servicios posibles: correo, web, etc.
Y ahora multiplica eso x2 para el archivado por capas que sugiere Rafa porque además de HA tienes que tenerlo todo almacenadito y con su backup correspondiente >:-)
No señor, no HAY que multiplicar x2 para archivar. Yo he mostrado opciones, que alguien quiere usar almacenamiento jerárquico con HSM y/o VTLs ... eso ya es cosa suya, yo he contado a grandes rasgos la tecnología que hay y cómo se puede implementar. Eso no significa que haya que hacerlo así. Tampoco hay que archivar una copia de cada servidor, ten en cuenta que los 2 servidores en HA comparten los datos y la configuración del servidor es la misma. Tampoco digo que TENGAS que archivar, digo que PUEDES archivar.
Metes todo el dinero que puedas en el hardware, más la electrónica. A partir de
aquí puedes usar buen software libre para montar dos servidores de storage en HA y los demás servidores dando servicio y te olvidas de esos problemas que se comentan de espacio en /var.
Ains, sí, eso no estaría mal. No siempre se empieza desde cero ni con todo el material que a uno le gustaría...
Y por cierto, todo y cuando y digo todo es todo, lo que se almacena en /var es
fácilmente movible a cualquier otro espacio de disco: bases de datos, spool del mta, etc. Todo. A mí no se me ocurre ningún caso en el que no se pueda hacer, aunque no digo que no lo haya pero no se me ocurre.
Nadie dice que no lo puedas mover, sólo que las colas no mantienen un tamaño predecible ni fijo. Y las colas suelen estar en /var (configuraciones personales/concretas aparte).
Por eso mismo he explicado por qué se diseñaron y desarrollaron dichas herramientas: porque hay sistemas de ficheros que NO son estáticos. Para que te hagas una idea, DMF (que es el HSM de SGI) lleva en el mercado 15 años así que es un problema conocido desde hace mucho tiempo y el archivado de datos ... más aún. Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Friday 23 April 2010 12:09 Camaleón wrote
El Fri, 23 Apr 2010 11:10:23 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 10:13 Camaleón wrote
Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail están archivados en cintas y almacenados allá en Mountain View? >:-)
Te sorprendería saber lo que hay en cinta y el usuario cree que está en disco. Te pongo un ejemplo que es mucho más "delicado": NBA. Está haciendo streaming en Internet de todos sus videos y creeme, la gran mayoría están en cinta. Es cliente nuestro ;)
La NBA no usa un servicio como Gmail :-)
Ya, pero hace streaming de video, lo cual tiene unas exigencias mayores en cuanto a disponibilidad del material por lo que si con un vídeo lo puedes hacer ... con un correo no te quiero contar lo qu epuedes hacer ;)
A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual,
¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber usado Youtube si quieres.
el volumen de datos que tiene que manejar la NBA no es el volumen de datos que tiene que manejar cualquier empresa ni las estrategias que tienen definidas, tampoco se ajustan a una empresa media.
Eso te lo he puesto más abajo. Entonces también tienes que reconocer que el ejemplo que has puesto tu (Google) tampoco "se ajustan a una empresa media.", como bien dices ;) Me he limitado a seguir tu ejemplo en cuanto a tamaño de empresa, complejidad de su negocio, volumen de datos, ... Si no te gusta la NBA como ejemplo qu ehe puesto ... tampoco te puede gustar Google como ejemplo que has puesto tu ;)
Otra cosa, no confundas cosas. Yo no he dicho que tenga que estar TODO
en cinta, he dicho cosas como (copio y pego): "2.- como admin, estableces reglas de migración que auto-
máticamente t emigran los correos más antiguos"
¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a los correos que tengo desde de la lista el año 2.003 es instantáneo, dudo mucho que los tengan almacenados como archivo.
¿Por qué? Ya te he explicado que es basado en políticas y que Google lo tiene todo muy estudiado. ¿Sabemos cómo monitorizan los correos y usuarios? Nopes. ¿Podrían estar monitorizando por usuario? Sí. ¿Podrían establecer reglas por usuario y volumen de datos? ¿Por qué no? Me puedes decir que eso es muy complicado, pero tambiés muy complicado su negocio de buscador y anuncios dirigidos ;) Obviamente, todo eso son suposiciones, así que te remito a lo que he dicho en correos anteriores y que aparece justo debajo: puede que usen discos SAS y como segundo nivel SATA. No sabemos cómo lo tienen montado por lo que tanto tu como yo lo único que podemos hacer es especular: - yo a favor de que sí tienen archivado - tu en contra de que tienen archivado Pero es eso, meras especulaciones ;) Así que mejor dejamos Google que no lo conocemos ni tu ni yo y es como discutir sobre el sexo de los ángeles ;) Yo te he puesto ejemplos reales que sí conozco, puedes ponerme ejemplos reales que tu sí conoces.
"Los ficheros más usados, se encuentran en los discos SAS, los
menos
usados en SATA y los que están llenos de polvo en cinta."
"Nada es eterno ;) Los datos/correos tarde o temprano se vuelven antiguos
y se pueden archivar."
"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa archiva en un día otra no lo llega a archivar en 5 años (debido a la diferencia entre la cantidad de datos que genera una y otra).
De ahí que hable tanto en los correos anteriores como ahora mismo de las reglas o políticas que cada empresa pone en función de sus flujos de trabajo (y órdenes/decisiones dle jefe). Me estás dando la razón, es lo que he dicho en correos anteriores: depende de la empresa, es la propia empresa la uqe tiene que decidir/definir sus políticas.
También es cierto que tus políticas no le valen a Google ni a la gestoría de la esquina ni a la NBA, cada caso es un mundo. Por eso, lo tienen que decidir el cliente final.
Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho ;-)
Volvemos a lo de antes: desde un punto de vista lógico, no físico y, te guste o no, tu almacenamiento y el de todo ser vivo, es físico. Luego si tienes: /dev/sdc1 -> /var /dev/sdd1 -> /var/log /dev/sde1 -> /var/BBDD /dev/sdf1 -> /var/correo_electronico_del_jefe ... Y crece /var/correo_electronico_del_jefe y /var/log ... /var/ crece de forma lógica, pero NO crece de forma física. Lo mismo ocurre si sólo tienes los siguientes 3 sistemas de ficheros: / /home /var y /var y /home crecen 100 TB ... / NO crece, seguirá teniendo el mismo tamaño que tuvo ayer a las 16:30 cuando lo instalaste. Crecimiento desde un punto de vista lógico NO implica crecimiento desde un punto de vista físico y a ti lo que te interesa es el crecimiento físico, el lógico te da igual.
En cuanto a Google, creeme, lo tienen todo muy bien estudiado y no me extrañaría que tuvieran en cinta mucha más info de la que creemos ;) No sólo Google sino otros como FaceBook o NYSE o cualquier otro grande.
Demasiado rápido va como para que esté archivado, no me convence.
Doy por hecho que has medido el tiempo de respuesta d etodos los correos de todos los usuarios de GMail ;) El que a ti te vaya deprisa NO significa que a mi me vaya deprisa. Otra cosa, te remito a lo que he dicho de los niveles de almacenamiento y a los ejemplos que te he puesto del video: puedes tener partes de dato on line y parte off-line así das la impresión que es on-line.
Sí, pero es que no hablamos de "archivar". Archivar implica dar un tratamiento especial a los datos, sacarlos de su ubicación actual y moverlos a otro espacio (físico o lógico) por lo que dejan de estar accesibles en tiempo real para el servidor o el usuario.
Volvemos a lo de antes, se supone que has hecho un estudio sobre qué datos y cuándo se pueden migrar porque no hace falta tiempo real. Este es el caso de correo-e, documentos ofimáticos, imágenes, ...
Pero Rafa, a ver... cómo te lo diría. Mi "/vares" crecen y necesito tener espacio disponible para que puedan aumentar hasta lo que quieran (hasta lo que le permita el disco)
Eso no es nada nuevo, le pasa a todo el mundo ;)
porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas. Con 1.2 TiB para espacio compartido de archivos y backup de momento nos sobra :-P
¿Y? Eso no significa que no lo vayas a necesitar. Pero ... volvemos a lo que he dicho en todos mis correos de este thread: - la empresa es la que decide así que si te funciona así, por mi bien, sigue así :D - yo no estoy intentando convencer a nadie de que use una determinada tecnología, me limito a contar la tecnología que existe Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo. Ya hubo un thread y no pienso entrar a resucitar dicho thread ni dicho tema. Se diferencia precisamente porque en tu frase puedes dar a entender que SÍ estas usando SW de archivado y que tienes archivados datos: "Con 1.2 TiB para espacio compartido de archivos y backup [...]" Esa frase la lee cualquier empresa de almacenamiento (EMC, Hitachi, SGI, HP, IBM, Oracle, ATEMPO, ...) y da por hecho que tienes un sw que te archiva y crea copias de seguridad. Es simplemente un consejo, ten cuidado porque puedes causar confusión, especialmente en un mercado que ya tiene unas palabras determinadas para determinadas situaciones. Es como si un usuario te dice que "este ordenador no funciona" y para él ordenador es sinónimo de teclado+ratón+monitor+CPU+tele+lavadora+video+TDT+SW ... te lo digo porque me ha pasado y no sabes de lo que están hablando y lo único que se consigue es alargar y liar una cosa que podía durar 2 minutos. Como ejemplo: la gente que confunde MS-Windows con MS-Office y meten en el saco el MSN. Hasta que sabes de lo qu ete están hablando ...
/var es para ficheros de tamao variable, de ahí el nombre.
Un "tamaño variable" requiere un "espacio variable" y esos datos pueden e estar ahí meses o años antes de pasar a ser archivados >:-)
Efectivamente y esa variación de tamaño luego se refleja en la cantidad
"variable" de dinero que quieras pagar: - disco -> más caro + más consumo + más calor
- cinta -> más barato + menos consumo + menos calor
Pero es que necesito que estén en disco y accesibles, no en cinta y archivados.
Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE TODOS los ficheros que hay en tus sistemas informáticos se usen SIEMPRE. No me lo creo. Necesitar != querer.
Oye, por mi encantado que NO quieras archivar y ójala todos los clientes pensaran así -> vendería más disco y me haría rico. Pero la realidad es
otra: "¿por qué pagar más por mantener un dato on-line cuando NO
es necesario que esté on-ĺine?"
Y creeme, que si el jefe y el de contabilidad/compras/financiero oyen "pagar más" o "pagar menos" ... la cosa cambia.
Porque cuesta (tiempo, dinero, mantenimiento) más llevarte ese dato offline que mantenerlo online. Y porque en el caso de los correos, necesitas tenerlos en línea, disponibles, frescos.
Necesitar != querer. Copio y pego: volvemos a lo que he dicho en todos mis correos de este thread: - la empresa es la que decide así que si te funciona así, por mi bien, sigue así :D - yo no estoy intentando convencer a nadie de que use una determinada tecnología, me limito a contar la tecnología que existe
Si tienes un disco pequeño, "/var" ni se parte ni se divide. No compensa, al contrario, te penaliza.
Si tienes un disco físico pequeño en *nix, hacerlo crecer es muy sencillo: compras un disco nuevo y lo montas bajo /var/disco_nuevo ;)
Eso será si te puedes permitir el lujo de comprar un disco nuevo y de más capacidad (hay quien no puede ni eso)
Ya lo sé y no he dado por hecho eso. Me he limitado a dar una solución técnica a un problema técnico.
y para los afortunados que pueden comprarlo y ampliar el espacio, tienen además que tener una configuración que admita la gestión de volumen dinámicos (el LVM que estábamos comentando)
Para la solución que yo he dado (montar un disco nuevo bajo /var/disco_nuevo) NO hace falta tener LVM.
y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
O a lo mejor no lo necesita porque montando el nuevo disco como he dicho en el ejemplo les vale. Te repito que NO estoy obligando a nadie a usar ninguna tecnología: - en el caso de LVM he dado unos consejos a un colistero - en el caso de archivado, HSM, DAM, dedupe, ... lo he comentado porque a lo mejor a alguien le parece útil y porque está relacionado con el tema de crecimiento de datos
Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar su tamaño o disminuirlo de forma aleatoria y sin un patrón concreto).
Por eso mismo existen: - gestores de volúmenes - sw de HSM - sw de archivado - dedupe
Inviable en muchas empresas.
Y dale, NO he dicho que sea obligatorio usarlo. Ya sé que es inviable en muchas empresas. En el párrafo mío anterior lo que hago es explicar por qué aparecieron esas herramientas, no te líes. Me he limitado a decir por qué se han diseñado y desarrollado esas tecnologías, no que sean obligatorias o necesarias. Ya sé que son inviables en muchas o algunas empresas, igual que es inviable que nos compremos todos (muchos o algunos) un Rolls Royce, pero eso no quita que alguin nos cuente por qué el Sr. Royce decidió diseñar y construir ese coche.
Imagina un correo enorme que tenga que estar en la cola dirigido a todos los usuarios del sistema enviado con malas intenciones,
Para eso se establecen límites en el tamaño del correo, entre otros límites ;) Si no estableces límites: mal hecho.
No, no puedes.
Sí puedes y de hecho debes hacerlo, si no pones límites en el correo, el uso de Inet, ... Se va todo al carajo.
Eso no depende de ti, y nosotros podemos recibir planos completos en AutoCAD por correo electrónico (no preguntes...). Tengo que relajar esas normas o podemos perder mucho, no sólo tiempo sino dinero.
Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo de empresa en la que trabajas y coincide con el tipo de empresa de algunos de nuestros clientes. Pero eso no quita que esté mal y no me vale el que digas: "Es que los usuarios se quejan o no quieren aprender a usar FTP". Mira, nosotros hemos llegado a recibir correos de 60 MByte de gente de marketing y no te quiero contar la cantidad de quejas que hubo, se les explicó: tenemos un FTP interno, pónlo allí. Posteriormente se decidió que presentaciones, manuales, vídeos, ... estuvieran en una web (wiki o web "normal") y que a la gente no técnica se les formara y que las webs se diseñasen para facilitarles la labor. Con esto qué hemos conseguido: - mayor fluidez en el correo - evitar enviarle el "documentazo" a gente a la que no le interesa - ahorrar en almacenamiento en el servidor de correo - ahorrar dinero - ahorrar molestias - ... Si tu se lo explicas bien al que maneja "los dineros" ... creeme que puedes poner las reglas que te dé la gana. Si montas una buena demo y lo pones fácil ... todos felices :) Como siempre: otro consejo. Hago esta aclaración porque vas a volver a interpretar que te quiero obligar o convencer a usar una tecnología. Ya que estamos con este tema de AutoCAD (y lo que conlleva: múltiples ficheros, desde docs, PDFs, fotos de terrenos, planos, ...) os vendría de perlas un DAM porque evitarías que la gente enviase tanto plano por correo ;) Claro está, que hay que elegir bien cuál, el flujo de datos, ... Tu decides ;)
e imagina además que por política de empresa todos los mensajes enviados/recibidos se duplican en una cuenta de seguridad... aumentas el espacio requerido en "/ var" de manera exponencial en apenas unos segundos.
Tu lo has dicho: es una COPIA, luego no es necesaria on-line porque tienes el original on-line.
No se trata de que esté o no archivada, se trata de que te ocupa espacio en disco... hasta que llegue a su destino. Y su destino puede ser "/var/ mail", donde la persona que se encargue de consultar esos correos lo haga mediante IMAP y ahí se quedan los correos hasta que al año siguiente se archivan.
A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que al año siguiente se archivan." Vuelves a darme la razón. Llevo todo este tiempo diciendo que se establecen políticas basadas en tiempo y el que establece ese tiempo es el cliente porque es el que sabe cómo funciona su empresa. En tu caso los archiváis anualmente, en otros sitios todoas las noches, en otros una vez a la semana. Que sí, que hasta que los archivas están en disco, vale, ¿y qué? Lo malo es que tuvieras en disco los de TODOS los años y que jamas archivaras.
Es un ejemplo de lo que en un correo anterior llamaba (o llaman algunos clientes/empresas) copia legal.
Esa copia puede estar perfectamente en una librería de cintas, bien sea con o sin VTL por en medio para darle mayor agilidad/velocidad al proceso o se hace todas las noches o la política que creas conveniente, pero es lo que tu misma has dicho: una copia.
Pero es que no hay un "caso de uso" único. Cada empresa o cada usuario tiene establecido un método de trabajo distinto, acorde a sus necesidades.
Yo no he dicho que haya un caos único. No te estás leyendo mis correos, estoy diciendo que cada empresa pondrá sus reglas o políticas. En mi párrafo anterior, de hecho, he escrito: " o se hace todas las noches o la política que creas conveniente" Ese "tu" puedes ser tu (Camaleón) o puede ser Carlos o Fernandito o Pepi o El director de Repsol o de Nike, me da igual quién sea. Cada uno pondrá sus reglas de acuerdo a su funcionamiento y necesidades.
¿Y cuándo se eliminan los correos pesados? Pues dependerá de cada usuario. Algunos lo descargaran vía pop, otros lo mantendrán accesible vía imap... y otros no lo bajarán en ¿meses?.
Pero ahí ya interviene la política de empresa. si la empresa dice que se hace así, así y así. Pues es como hay que hacerlo. Los recursos son de la empresa, nos guste o no y es la empresa la que establece las normas. Obviamente, si tu como Admin le consigues explicar bien las cosas al jefe ... se harán "bien".
Si tu, como Admin, rechazas una tecnología porque sí ... a lo mejor te estás perdiendo una cosa que te ahorraría mucha pasta y que podrías invertir en cosas que necesitas: formación, renovación de equipos, ...
Rafa, hay muchas formas de hacer las cosas bien. Ya me gustaría a mí poder tener los servidores web (o los de correo) en HA, o al menos re- duplicados. No puedo. O aumentar el almacenamiento de la red local. No puedo. Tengo que trabajar con lo que hay y rentabilizar no sólo en material sino en tiempo >:-)
Por eso he comentado algunas tecnologías de almacenamiento. Yo no obligo a que se usen, las doy a ocnocer. A lo mejor ahora mismo no puedes/necesitas hacer uso de ellas. Pero a lo mejor dentro de XXXXX años te surge un problema y piensas: "Un carajo de la lista me comentó una vez algo llamado dedupe/LVM/archivado/HSM/lava_vajillas/escobilla/buzón/tenedor que me vendría bien": También puede ocurrir que tu (Camaleón) jamás lo puedas implementar pero otros sí. O, a lo mejor nadie ne esta lista lo necesite jamás. Eso ya no es "mi problema", yo lo cuento y ya está, luego que cada uno decida.
O el mismo "zypper" te puede disparar las necesidades de espacio actuales en "/var" al generar archivos de registro de actividad de "no-sé-cuantos" gigas por un error.
Ahí hay otra tecnología que se llama thin provisioning u oversubscription. También hay una cosa que se llama previsión, como Admin tienes que preveer la cantidad de un recurso que vas a necesitar. Obviamente es IMPOSIBLE acertar con las predicciones, pero tienes una idea.
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
Buena práctica :D
Te vuelvo a repetir: no te estoy inentando convencer de que uses o no una tecnología (sea de gestión de almacenamiento, como es este caso) o sea de monitorización de cámaras IP. Yo te comento lo que hay, lo que se usa, en qué casos, ... que a ti te guste o no, que te convenzca, que te parezca bueno o no, ... Oye, ya es cosa tuya: yo sólo intento ayudar porque he visto que en casos similares ... sí ha funcionado ;)
Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-)
No señor, tenemos empresas medianas que usan estas tecnologías. Y otros fabricantes también tienen empresas medianas que usan esas tecnologías. Yo he puesto los casos extremos para que veáis casos en los que es PRIMORDIAL, es decir, que a Pepito el streaming no le vaya del todo fino no es importante para la Humanidad, ahora que no le vaya fino a NBA es un desastre mundial (bueno, para todos a los que les guste el baloncesto ... a mi personalmente me importa un bledo*, a mi lo que me gusta es el skate y el snow ;) * lo cual no significa que me importa un bledo a nivel corporativo como fabricante ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 23 Apr 2010 13:32:35 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 12:09 Camaleón wrote
La NBA no usa un servicio como Gmail :-)
Ya, pero hace streaming de video, lo cual tiene unas exigencias mayores en cuanto a disponibilidad del material por lo que si con un vídeo lo puedes hacer ... con un correo no te quiero contar lo qu epuedes hacer ;)
El streaming de vídeo no es de acceso lectura/escritura, que yo sepa >:-) El correo, sí. Y por parte de varios usuarios al mismo tiempo.
A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual,
¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber usado Youtube si quieres.
Hijo, pues no. La NBA no es una empresita del montón, la verdad.
el volumen de datos que tiene que manejar la NBA no es el volumen de datos que tiene que manejar cualquier empresa ni las estrategias que tienen definidas, tampoco se ajustan a una empresa media.
Eso te lo he puesto más abajo. Entonces también tienes que reconocer que el ejemplo que has puesto tu (Google) tampoco "se ajustan a una empresa media.", como bien dices ;)
Te he puesto como ejemplo cualquier empresa vulgaris pero tú dices que no, que eso de mantener los correos en línea no era la norma. Ahí es cuando te he puesto como ejemplo a Gmail. Podría haber dicho cualquier otra empresa que dé servicio IMAP (o en la nube).
¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a los correos que tengo desde de la lista el año 2.003 es instantáneo, dudo mucho que los tengan almacenados como archivo.
(...)
Yo te he puesto ejemplos reales que sí conozco, puedes ponerme ejemplos reales que tu sí conoces.
Pero eso no es justo. Que yo no conozca ninguna empresa de primera mano que siga una política determina no significa que no las haya. No es mi campo (servicios a terceras empresas), no lo puedo saber.
"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa archiva en un día otra no lo llega a archivar en 5 años (debido a la diferencia entre la cantidad de datos que genera una y otra).
De ahí que hable tanto en los correos anteriores como ahora mismo de las reglas o políticas que cada empresa pone en función de sus flujos de trabajo (y órdenes/decisiones dle jefe). Me estás dando la razón, es lo que he dicho en correos anteriores: depende de la empresa, es la propia empresa la uqe tiene que decidir/definir sus políticas.
Vale, pues te doy la razón en lo del "factor tiempo" :-)
Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho ;-)
Volvemos a lo de antes: desde un punto de vista lógico, no físico y, te guste o no, tu almacenamiento y el de todo ser vivo, es físico. Luego si tienes: /dev/sdc1 -> /var /dev/sdd1 -> /var/log /dev/sde1 -> /var/BBDD /dev/sdf1 -> /var/correo_electronico_del_jefe ...
Y crece /var/correo_electronico_del_jefe y /var/log ... /var/ crece de forma lógica, pero NO crece de forma física.
A ver, a ver... 20 GiB son 20 GiB que necesitan espacio físico si tienes un disco duro de 60 GiB y si no tienes espacio, el sistema se queda colgado, no puedes iniciar sesión, los correos se rebotan, etc...
Lo mismo ocurre si sólo tienes los siguientes 3 sistemas de ficheros: / /home /var
y /var y /home crecen 100 TB ... / NO crece, seguirá teniendo el mismo tamaño que tuvo ayer a las 16:30 cuando lo instalaste. Crecimiento desde un punto de vista lógico NO implica crecimiento desde un punto de vista físico y a ti lo que te interesa es el crecimiento físico, el lógico te da igual.
¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición), pero la cantidad de datos se incrementa con cada copia de seguridad que hago, o con cada correo o con cada fax que se envía o se recibe.
porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas. Con 1.2 TiB para espacio compartido de archivos y backup de momento nos sobra :-P
¿Y? Eso no significa que no lo vayas a necesitar. Pero ... volvemos a lo que he dicho en todos mis correos de este thread:
- la empresa es la que decide así que si te funciona así, por mi bien, sigue así :D
- yo no estoy intentando convencer a nadie de que use una determinada tecnología, me limito a contar la tecnología que existe
La tecnología existe, por supuesto. Pero no siempre merece la pena implementarlas.
Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo. Ya hubo un thread y no pienso entrar a resucitar dicho thread ni dicho tema. Se diferencia precisamente porque en tu frase puedes dar a entender que SÍ estas usando SW de archivado y que tienes archivados datos:
"Con 1.2 TiB para espacio compartido de archivos y backup [...]"
Esa frase la lee cualquier empresa de almacenamiento (EMC, Hitachi, SGI, HP, IBM, Oracle, ATEMPO, ...) y da por hecho que tienes un sw que te archiva y crea copias de seguridad.
Sí, lo uso (en este caso "tar"). Lo que crean que tengo o dejo de tener el resto de empresas es problema de ellas. Si quieren más datos, que me pregunten ;-)
Es simplemente un consejo, ten cuidado porque puedes causar confusión, especialmente en un mercado que ya tiene unas palabras determinadas para determinadas situaciones. Es como si un usuario te dice que "este ordenador no funciona" y para él ordenador es sinónimo de teclado+ratón+monitor+CPU+tele+lavadora+video+TDT+SW ... te lo digo porque me ha pasado y no sabes de lo que están hablando y lo único que se consigue es alargar y liar una cosa que podía durar 2 minutos.
Como ejemplo: la gente que confunde MS-Windows con MS-Office y meten en el saco el MSN. Hasta que sabes de lo qu ete están hablando ...
Me encanta que la gente dude de esas cosas o que sencillamente no sepa qué término usar. Verás, la RAE es un muy clara al respecto sobre el término "archivo" y si la gente quiere hacer un uso forzado o una interpretación propia del lenguaje es problema de ellos :-) Yo no tengo ninguna duda sobre el término adecuado.
Pero es que necesito que estén en disco y accesibles, no en cinta y archivados.
Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE TODOS los ficheros que hay en tus sistemas informáticos se usen SIEMPRE. No me lo creo.
Necesitar != querer.
Ya te dije que sí. Al menos yo necesito tener los faxes recibidos/ enviados de hace 3 años bajo /var/spool/hylafax... o eso o empiezo a montar el servidor desde cero integrando alguna de esas soluciones que comentabas -> inviable, al menos de momento.
y para los afortunados que pueden comprarlo y ampliar el espacio, tienen además que tener una configuración que admita la gestión de volumen dinámicos (el LVM que estábamos comentando)
Para la solución que yo he dado (montar un disco nuevo bajo /var/disco_nuevo) NO hace falta tener LVM.
Entonces te encontrarás con el mismo problema de limitación de espacio.
y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
O a lo mejor no lo necesita porque montando el nuevo disco como he dicho en el ejemplo les vale. Te repito que NO estoy obligando a nadie a usar ninguna tecnología:
Ya sabemos que no obligas a nadie... (¿qué hace esta argolla con pinchos alrededor de mi cuello?) :-P
Eso no depende de ti, y nosotros podemos recibir planos completos en AutoCAD por correo electrónico (no preguntes...). Tengo que relajar esas normas o podemos perder mucho, no sólo tiempo sino dinero.
Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo de empresa en la que trabajas y coincide con el tipo de empresa de algunos de nuestros clientes. Pero eso no quita que esté mal y no me vale el que digas: "Es que los usuarios se quejan o no quieren aprender a usar FTP".
Exacto: no quiere usar el FTP. A tus usuarios los puedes "domesticar" (quiero decir, intentar hacerles comprender cómo hacer bien las cosas) pero a los usuarios de empresas asociadas o con las que trabajas, ah, amigo... esos no son tuyos y entienden la vida de otra forma... si te gusta vale, y si no, adiós contrato. Es así. (...)
Como siempre: otro consejo. Hago esta aclaración porque vas a volver a interpretar que te quiero obligar o convencer a usar una tecnología. Ya que estamos con este tema de AutoCAD (y lo que conlleva: múltiples ficheros, desde docs, PDFs, fotos de terrenos, planos, ...) os vendría de perlas un DAM porque evitarías que la gente enviase tanto plano por correo ;)
¡¡¡Argghhh, más siglas...!!! X-)
No se trata de que esté o no archivada, se trata de que te ocupa espacio en disco... hasta que llegue a su destino. Y su destino puede ser "/var/ mail", donde la persona que se encargue de consultar esos correos lo haga mediante IMAP y ahí se quedan los correos hasta que al año siguiente se archivan.
A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que al año siguiente se archivan." Vuelves a darme la razón. Llevo todo este tiempo diciendo que se establecen políticas basadas en tiempo y el que establece ese tiempo es el cliente porque es el que sabe cómo funciona su empresa.
He dicho "un año" por decir... pueden ser 5, o 10... y el /var sigue creciendo a diario.
Pero es que no hay un "caso de uso" único. Cada empresa o cada usuario tiene establecido un método de trabajo distinto, acorde a sus necesidades.
Yo no he dicho que haya un caos único. No te estás leyendo mis correos, estoy diciendo que cada empresa pondrá sus reglas o políticas. En mi párrafo anterior, de hecho, he escrito:
" o se hace todas las noches o la política que creas conveniente"
Ese "tu" puedes ser tu (Camaleón) o puede ser Carlos o Fernandito o Pepi o El director de Repsol o de Nike, me da igual quién sea. Cada uno pondrá sus reglas de acuerdo a su funcionamiento y necesidades.
Vale, entendido.
Rafa, hay muchas formas de hacer las cosas bien. Ya me gustaría a mí poder tener los servidores web (o los de correo) en HA, o al menos re- duplicados. No puedo. O aumentar el almacenamiento de la red local. No puedo. Tengo que trabajar con lo que hay y rentabilizar no sólo en material sino en tiempo >:-)
Por eso he comentado algunas tecnologías de almacenamiento. Yo no obligo a que se usen, las doy a ocnocer. A lo mejor ahora mismo no puedes/necesitas hacer uso de ellas. Pero a lo mejor dentro de XXXXX años te surge un problema y piensas: "Un carajo de la lista me comentó una vez algo llamado dedupe/LVM/archivado/HSM/lava_vajillas/escobilla/buzón/tenedor que me vendría bien": También puede ocurrir que tu (Camaleón) jamás lo puedas implementar pero otros sí. O, a lo mejor nadie ne esta lista lo necesite jamás. Eso ya no es "mi problema", yo lo cuento y ya está, luego que cada uno decida.
Y todos (al menos yo) te lo agradecemos O:-). Por ejemplo, con lo de los discos SAS en cabinas externas me diste una buena idea.
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
Buena práctica :D
Hasta que algún día tenga problemas con "la" partición, claro :-P
Yo creo que tus "user-case", aunque totalmente válidos (repito, ya me gustaría poder mantener ese tipo de configuración), están un poco sobredimensionados en comparación con los requerimientos de las empresas medias O:-)
No señor, tenemos empresas medianas que usan estas tecnologías. Y otros fabricantes también tienen empresas medianas que usan esas tecnologías. Yo he puesto los casos extremos para que veáis casos en los que es PRIMORDIAL, es decir, que a Pepito el streaming no le vaya del todo fino no es importante para la Humanidad, ahora que no le vaya fino a NBA es un desastre mundial (bueno, para todos a los que les guste el baloncesto ... a mi personalmente me importa un bledo*, a mi lo que me gusta es el skate y el snow ;)
Y los caracoles...
* lo cual no significa que me importa un bledo a nivel corporativo como fabricante ;)
Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Friday 23 April 2010 14:12 Camaleón wrote
El Fri, 23 Apr 2010 13:32:35 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 12:09 Camaleón wrote
La NBA no usa un servicio como Gmail :-)
Ya, pero hace streaming de video, lo cual tiene unas exigencias mayores en cuanto a disponibilidad del material por lo que si con un vídeo lo puedes hacer ... con un correo no te quiero contar lo qu epuedes hacer ;)
El streaming de vídeo no es de acceso lectura/escritura, que yo sepa >:-)
Eso es que no conoces cómo funciona el mundo media. Toda slas televisiones y productoras tienen escritura y lectura simultáneamet y por varios usuarios: - unos editando contenidos - otros catalogando - otros creando - ... La NBA, como buena productora y TV que es ... funciona así así que sí, hay lectura y ecritura al mismo tiempo en tiempo real y por varias personas.
El correo, sí. Y por parte de varios usuarios al mismo tiempo.
A ver, que tú pones como ejemplo un tipo de industria/usuario que no es el habitual,
¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber usado Youtube si quieres.
Hijo, pues no. La NBA no es una empresita del montón, la verdad.
Google tampoco ;)
el volumen de datos que tiene que manejar la NBA no es el volumen de datos que tiene que manejar cualquier empresa ni las estrategias que tienen definidas, tampoco se ajustan a una empresa media.
Eso te lo he puesto más abajo. Entonces también tienes que reconocer que el ejemplo que has puesto tu (Google) tampoco "se ajustan a una empresa media.", como bien dices ;)
Te he puesto como ejemplo cualquier empresa vulgaris pero tú dices que no, que eso de mantener los correos en línea no era la norma. Ahí es cuando te he puesto como ejemplo a Gmail. Podría haber dicho cualquier otra empresa que dé servicio IMAP (o en la nube).
¿Google vulgaris? Eso es nuevo: si mal no recuerdo, tienen más de 1 millón de servidores. Es más, eGoogle puede que tengas más razón en que no puedan archivar correo, pero en una empresa pequeña/mediana que los trabajadores se van a casa ... razón de más para poder archivar, mojer y hacer lo que te da la gana: no hay nadie usándolo (bueno, siempre hay alguien conectado), pero reclama el correo, fichero, dato y solucionado. De hecho, te he puesto ejemplos en los que el usuario no sabe ni que está trabajando contra cinta.
¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a los correos que tengo desde de la lista el año 2.003 es instantáneo, dudo mucho que los tengan almacenados como archivo.
(...)
Yo te he puesto ejemplos reales que sí conozco, puedes ponerme ejemplos reales que tu sí conoces.
Pero eso no es justo. Que yo no conozca ninguna empresa de primera mano que siga una política determina no significa que no las haya. No es mi campo (servicios a terceras empresas), no lo puedo saber.
Yo sí, y ya te he dicho que tenemos clientes grandes y pequeños que lo hacen. Lo cual no quiere decir que todo el mundo lo deba hacer. Sólo digo que sí pueden y de hecho lo hacen.
"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa archiva en un día otra no lo llega a archivar en 5 años (debido a la diferencia entre la cantidad de datos que genera una y otra).
De ahí que hable tanto en los correos anteriores como ahora mismo de las reglas o políticas que cada empresa pone en función de sus flujos de trabajo (y órdenes/decisiones dle jefe). Me estás dando la razón, es lo que he dicho en correos anteriores: depende de la empresa, es la propia empresa la uqe tiene que decidir/definir sus políticas.
Vale, pues te doy la razón en lo del "factor tiempo" :-)
Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho ;-)
Volvemos a lo de antes: desde un punto de vista lógico, no físico y, te guste o no, tu almacenamiento y el de todo ser vivo, es físico. Luego si
tienes: /dev/sdc1 -> /var /dev/sdd1 -> /var/log /dev/sde1 -> /var/BBDD /dev/sdf1 -> /var/correo_electronico_del_jefe ...
Y crece /var/correo_electronico_del_jefe y /var/log ... /var/ crece de forma lógica, pero NO crece de forma física.
A ver, a ver... 20 GiB son 20 GiB que necesitan espacio físico si tienes un disco duro de 60 GiB y si no tienes espacio, el sistema se queda colgado, no puedes iniciar sesión, los correos se rebotan, etc...
Correcto, de ahí que te haya hablado de: - tecnologías ue te permiten ampliar, archivar, ... - previsiones - montar un segundo disco y descargar datos "amanuense" Eso jamás te lo he negado. Lo que digo es que si crece /var/algo en su propio sistema de ficheros, /var (que está en SU sistema de ficheors) NO crece de forma física.
Lo mismo ocurre si sólo
tienes los siguientes 3 sistemas de ficheros: / /home /var
y /var y /home crecen 100 TB ... / NO crece, seguirá teniendo el mismo tamaño que tuvo ayer a las 16:30 cuando lo instalaste. Crecimiento desde un punto de vista lógico NO implica crecimiento desde un punto de vista físico y a ti lo que te interesa es el crecimiento físico, el lógico te da igual.
¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición), pero la cantidad de datos se incrementa con cada copia de seguridad que hago, o con cada correo o con cada fax que se envía o se recibe.
A ver, tú has escrito "Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho > ;-)" Y yo he dicho que no, que lo que crece es el sistema de ficheros (mejor dicho, el volumen de datos de un sistema de ficheros) y que si /var y /var/algo son dos sistemas de ficheros diferentes y el que crece es /var/algo ... /var no crece. Y eso mismo le he respondido a Carlos. En cuanto a que: "¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición)" tampoco es cierto ya que si usas LVM o una solución de HSM, el crecimiento es hatsa que te dé el bolsillo ;) No depende del disco físico que haya debajo. Tu disco puede ser de 1 TB, pero con LVM puedes ir añadiendo discos de 1 TB hasta que te quedes sin dinero.
porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas. Con 1.2 TiB para espacio compartido de archivos y backup de momento nos sobra :-P
¿Y? Eso no significa que no lo vayas a necesitar. Pero ... volvemos a lo
que he dicho en todos mis correos de este thread: - la empresa es la que decide así que si te funciona así,
por mi bien, sigue así :D
- yo no estoy intentando convencer a nadie de que use una
determinada tecnología, me limito a contar la tecnología que
existe
La tecnología existe, por supuesto. Pero no siempre merece la pena implementarlas.
Yo no he dicho que merezca la pena, ni que sea obligatorio ni necesario. He dicho que es interesante tenerlas en cuenta y conocerlas, que es diferente. [...]
Pero es que necesito que estén en disco y accesibles, no en cinta y archivados.
Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE TODOS los ficheros que hay en tus sistemas informáticos se usen SIEMPRE. No me lo creo.
Necesitar != querer.
Ya te dije que sí. Al menos yo necesito tener los faxes recibidos/ enviados de hace 3 años bajo /var/spool/hylafax... o eso o empiezo a montar el servidor desde cero integrando alguna de esas soluciones que comentabas -> inviable, al menos de momento.
Eso lo dices porque no has usado sistemas de HSM, si los hubieras usado verías que no NECESITAS que estén on-line. El usuario no sabe ni dónde están ni se da cuenta si tarda en venir o no de cinta a disco. Te he puesto ejemplos de vídeo que es TIEMPO REAL, si pierdes un frame ... al carajo todo. Y allí funciona. También te he dicho que nosotros y otros fabricantes lo implementan para todo tipo de ficheros: ofimática, imágenes, ... Estás haciendo suposiciones sobre algo que no has usado y no conoces. Yo lo he visto en clientes grandes y pequeños, con necesidades de tiempo real y no y el usuario no se da cuenta.
y para los afortunados que pueden comprarlo y ampliar el espacio, tienen además que tener una configuración que admita la gestión de volumen dinámicos (el LVM que estábamos comentando)
Para la solución que yo he dado (montar un disco nuevo bajo /var/disco_nuevo) NO hace falta tener LVM.
Entonces te encontrarás con el mismo problema de limitación de espacio.
No digo que no te encuentres de nuevo con el problema, sólo he dicho que no es necesario tener LVM. Depende de cómo quieras solucionar el problema. También te podía haber puesto como solución el comprar una cabina de discos externa. (cabina de discos de SGI, claro está ;)
y hay quien sencillamente no quiere usar ese tipo de soluciones porque no les compensa.
O a lo mejor no lo necesita porque montando el nuevo disco como he dicho en el ejemplo les vale. Te repito que NO estoy obligando a nadie a usar
ninguna tecnología: Ya sabemos que no obligas a nadie...
(¿qué hace esta argolla con pinchos alrededor de mi cuello?)
No es de pinchos, son explosivos ... Mira que les tengo dicho a los de marketing que los explosivos en forma de pincho crean confusión. Nada, que no hay manera ... x"D
Eso no depende de ti, y nosotros podemos recibir planos completos en AutoCAD por correo electrónico (no preguntes...). Tengo que relajar esas normas o podemos perder mucho, no sólo tiempo sino dinero.
Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo de empresa en la que trabajas y coincide con el tipo de empresa de algunos de nuestros clientes. Pero eso no quita que esté mal y no me vale el que digas: "Es que los usuarios se quejan o no quieren aprender a usar FTP".
Exacto: no quiere usar el FTP.
A tus usuarios los puedes "domesticar" (quiero decir, intentar hacerles comprender cómo hacer bien las cosas) pero a los usuarios de empresas asociadas o con las que trabajas, ah, amigo... esos no son tuyos y entienden la vida de otra forma... si te gusta vale, y si no, adiós contrato. Es así.
No es cierto y lo he vivido con clientes nuestros. Han migrado a DAM y proveedores y usuarios internos trabajan tan contentos. ¿Saben realmente que es un FTP o un WebDAV o un CIFS? No. ¿Lo tienen que saber? No. Tu le das una interfaz web o si quieres les programas un cliente nativo para su sistema operativo o un cliente XUL para Firefox o como te de la gana o creas que es más sencillo para el usuario y ya está. Generalmente lo más sencilo para el uusario es una interfaz web.
Como siempre: otro consejo. Hago esta aclaración porque vas a volver a interpretar que te quiero obligar o convencer a usar una tecnología. Ya que estamos con este tema de AutoCAD (y lo que conlleva: múltiples ficheros, desde docs, PDFs, fotos de terrenos, planos, ...) os vendría de perlas un DAM porque evitarías que la gente enviase tanto plano por correo ;)
¡¡¡Argghhh, más siglas...!!! X-)
Ya lo puse en un corre anterior ;)
No se trata de que esté o no archivada, se trata de que te ocupa espacio en disco... hasta que llegue a su destino. Y su destino puede ser "/var/ mail", donde la persona que se encargue de consultar esos correos lo haga mediante IMAP y ahí se quedan los correos hasta que al año siguiente se archivan.
A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que al año siguiente se archivan." Vuelves a darme la razón. Llevo todo este tiempo diciendo que se establecen políticas basadas en tiempo y el que establece ese tiempo es el cliente porque es el que sabe cómo funciona su empresa.
He dicho "un año" por decir... pueden ser 5, o 10... y el /var sigue creciendo a diario.
Me da igual. El cliente es el que establece las políticas y es el que las modifica. He comentado en otro correo que los 3 - 4 primeros meses, el cliente modifica las reglas para irlo tuneando o afinando para sus necesidades, pero a partir del 6 mes ... eso no lo vuelve a tocar nadie (a menos que los flujos de trabajo cambien). [...]
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
Buena práctica :D
Hasta que algún día tenga problemas con "la" partición, claro :-P
Hmmmm, para ese tipo de problemas se me ocurre: LVM Archivado HSM x"D Es una broma. Lo que sí recomiendo es que no tengas datos y backups en el mismo sitio: si pierdes uno ... pierdes el otro :( [...]
... a mi personalmente me importa un bledo*, a mi lo que me gusta es el skate y el snow ;)
Y los caracoles...
Que no falten !!! x"D Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 23 Apr 2010 14:51:05 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 14:12 Camaleón wrote
Ya, pero hace streaming de video, lo cual tiene unas exigencias mayores en cuanto a disponibilidad del material por lo que si con un vídeo lo puedes hacer ... con un correo no te quiero contar lo qu epuedes hacer ;)
El streaming de vídeo no es de acceso lectura/escritura, que yo sepa
:-)
Eso es que no conoces cómo funciona el mundo media. Toda slas televisiones y productoras tienen escritura y lectura simultáneamet y por varios usuarios: - unos editando contenidos - otros catalogando - otros creando - ...
La NBA, como buena productora y TV que es ... funciona así así que sí, hay lectura y ecritura al mismo tiempo en tiempo real y por varias personas.
¿En "streaming"? ¿Todos editando el flujo de datos en tiempo real? caray, eso sería interesnate de ver...
¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber usado Youtube si quieres.
Hijo, pues no. La NBA no es una empresita del montón, la verdad.
Google tampoco ;)
Claro, pero es que si te digo que cualquier empresa del montón necesita disponer de esos datos en tiempo real (no archivados) no me crees. Por eso he puesto como ejemplo es servicio IMAP de Gmail.
Te he puesto como ejemplo cualquier empresa vulgaris pero tú dices que no, que eso de mantener los correos en línea no era la norma. Ahí es cuando te he puesto como ejemplo a Gmail. Podría haber dicho cualquier otra empresa que dé servicio IMAP (o en la nube).
¿Google vulgaris? Eso es nuevo: si mal no recuerdo, tienen más de 1 millón de servidores.
Es más, eGoogle puede que tengas más razón en que no puedan archivar correo, pero en una empresa pequeña/mediana que los trabajadores se van a casa ... razón de más para poder archivar, mojer y hacer lo que te da la gana: no hay nadie usándolo (bueno, siempre hay alguien conectado), pero reclama el correo, fichero, dato y solucionado. De hecho, te he puesto ejemplos en los que el usuario no sabe ni que está trabajando contra cinta.
Sigo sin ver claro eso de acceder a los correos mediante IMAP tirando de un archivo ubicado en una cinta, de verdad... como no sea un buen sistema de cinta, rápido y fiable, te echan a perder la copia en pocos días y la cinta, a la basura. ¿Tiene límites de escritura, no?
A ver, a ver... 20 GiB son 20 GiB que necesitan espacio físico si tienes un disco duro de 60 GiB y si no tienes espacio, el sistema se queda colgado, no puedes iniciar sesión, los correos se rebotan, etc...
Correcto, de ahí que te haya hablado de: - tecnologías ue te permiten ampliar, archivar, ... - previsiones - montar un segundo disco y descargar datos "amanuense"
Eso jamás te lo he negado. Lo que digo es que si crece /var/algo en su propio sistema de ficheros, /var (que está en SU sistema de ficheors) NO crece de forma física.
No pillo ese "no crecimiento físico" del que hablas. Los datos ocupan espacio físico, estén en /var, en /home o en cualquier otro lado (recurso de red, servidor remoto...).
¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición), pero la cantidad de datos se incrementa con cada copia de seguridad que hago, o con cada correo o con cada fax que se envía o se recibe.
A ver, tú has escrito
"Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho > ;-)"
Y yo he dicho que no, que lo que crece es el sistema de ficheros (mejor dicho, el volumen de datos de un sistema de ficheros) y que si /var y /var/algo son dos sistemas de ficheros diferentes y el que crece es /var/algo ... /var no crece. Y eso mismo le he respondido a Carlos.
Ah, ya, que dabas por hecho que /var/*/ está particionado. Aún así, está limitado por el tamaño de la partición que lo contiene y los datos crecen de la misma forma. No en "/var", pero sí en "/var/ mail" (por ejemplo). Estás con el mismo problema.
En cuanto a que:
"¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición)"
tampoco es cierto ya que si usas LVM o una solución de HSM, el crecimiento es hatsa que te dé el bolsillo ;) No depende del disco físico que haya debajo. Tu disco puede ser de 1 TB, pero con LVM puedes ir añadiendo discos de 1 TB hasta que te quedes sin dinero.
Ya, ya... vale.
Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE TODOS los ficheros que hay en tus sistemas informáticos se usen SIEMPRE. No me lo creo.
Necesitar != querer.
Ya te dije que sí. Al menos yo necesito tener los faxes recibidos/ enviados de hace 3 años bajo /var/spool/hylafax... o eso o empiezo a montar el servidor desde cero integrando alguna de esas soluciones que comentabas -> inviable, al menos de momento.
Eso lo dices porque no has usado sistemas de HSM, si los hubieras usado verías que no NECESITAS que estén on-line. El usuario no sabe ni dónde están ni se da cuenta si tarda en venir o no de cinta a disco. Te he puesto ejemplos de vídeo que es TIEMPO REAL, si pierdes un frame ... al carajo todo. Y allí funciona. También te he dicho que nosotros y otros fabricantes lo implementan para todo tipo de ficheros: ofimática, imágenes, ...
Estás haciendo suposiciones sobre algo que no has usado y no conoces. Yo lo he visto en clientes grandes y pequeños, con necesidades de tiempo real y no y el usuario no se da cuenta.
Hay muchas cosas que no conozco, Rafa. Lo que sí se es que implementar esas soluciones integradas que dices cuestan tiempo y dinero. Que sí, que están muy bien. Sólo te digo que en nuestro caso en concreto no es una opción justificable. Es más, si me dieran presupuesto, preferiría actualizar los routers, actualizar los switches de la red2 a gigabit (pasar de "10/100" a "1000" se nota... y mucho), añadir algún cortafuegos más o traer una estación de trabajo nueva. Tenemos otras prioridades antes que el almacenamiento.
Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo de empresa en la que trabajas y coincide con el tipo de empresa de algunos de nuestros clientes. Pero eso no quita que esté mal y no me vale el que digas: "Es que los usuarios se quejan o no quieren aprender a usar FTP".
Exacto: no quiere usar el FTP.
A tus usuarios los puedes "domesticar" (quiero decir, intentar hacerles comprender cómo hacer bien las cosas) pero a los usuarios de empresas asociadas o con las que trabajas, ah, amigo... esos no son tuyos y entienden la vida de otra forma... si te gusta vale, y si no, adiós contrato. Es así.
No es cierto y lo he vivido con clientes nuestros. Han migrado a DAM y proveedores y usuarios internos trabajan tan contentos. ¿Saben realmente que es un FTP o un WebDAV o un CIFS? No. ¿Lo tienen que saber? No. Tu le das una interfaz web o si quieres les programas un cliente nativo para su sistema operativo o un cliente XUL para Firefox o como te de la gana o creas que es más sencillo para el usuario y ya está. Generalmente lo más sencilo para el uusario es una interfaz web.
Rafa, yo no puedo controlar a nuestros proveedores ni decirles cómo tienen que hacer las cosas. Nos mandan a freír monas. Si ellos quieren enviar por e-mail lo que tengan que enviar lo hacen a su modo o como buenamente puedan/sepan (una memoria completa en PDF de un proyecto puede ocupar más que un sólo archivo de CAD con los planos o los cálculos de las estructuras) . A ver, cada proveedor es distinto. Con unos sí podemos hacerlo (porque llevamos más tiempo trabajando con ellos, sabemos su metodología y ellos la nuestra, hemos establecido un protocolo de actuación, etc...) pero con los que tenemos poca relación, no.
¡¡¡Argghhh, más siglas...!!! X-)
Ya lo puse en un corre anterior ;)
No llevo la cuenta O:-)
A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que al año siguiente se archivan." Vuelves a darme la razón. Llevo todo este tiempo diciendo que se establecen políticas basadas en tiempo y el que establece ese tiempo es el cliente porque es el que sabe cómo funciona su empresa.
He dicho "un año" por decir... pueden ser 5, o 10... y el /var sigue creciendo a diario.
Me da igual. El cliente es el que establece las políticas y es el que las modifica. He comentado en otro correo que los 3 - 4 primeros meses, el cliente modifica las reglas para irlo tuneando o afinando para sus necesidades, pero a partir del 6 mes ... eso no lo vuelve a tocar nadie (a menos que los flujos de trabajo cambien).
Pero es que sigues dando por hecho que se tiene que archivar todo cada poco tiempo y yo no lo veo así.
Por eso evito particionar pero me encargo de tener siempre los backups al día :-P
Buena práctica :D
Hasta que algún día tenga problemas con "la" partición, claro :-P
Hmmmm, para ese tipo de problemas se me ocurre: LVM Archivado HSM
x"D
Es una broma. Lo que sí recomiendo es que no tengas datos y backups en el mismo sitio: si pierdes uno ... pierdes el otro :(
Son discos duros independientes. Y el backup está "deduplicado" (ya uso la misma jerga :-P) en otro disco de red. Además, los datos importantes están (ahora sí) archivados en un DVD (cogiendo polvo). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Friday 23 April 2010 15:26 Camaleón wrote
El Fri, 23 Apr 2010 14:51:05 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 14:12 Camaleón wrote
Ya, pero hace streaming de video, lo cual tiene unas exigencias mayores en cuanto a disponibilidad del material por lo que si con un vídeo lo puedes hacer ... con un correo no te quiero contar lo qu epuedes hacer ;)
El streaming de vídeo no es de acceso lectura/escritura, que yo sepa
:-)
Eso es que no conoces cómo funciona el mundo media. Toda slas televisiones y productoras tienen escritura y lectura simultáneamet y
por varios usuarios: - unos editando contenidos - otros catalogando - otros creando - ...
La NBA, como buena productora y TV que es ... funciona así así que sí, hay lectura y ecritura al mismo tiempo en tiempo real y por varias personas.
¿En "streaming"? ¿Todos editando el flujo de datos en tiempo real? caray, eso sería interesnate de ver...
No Camaleón, nadie ha dicho que estén editando TODOS en tiempo real, te he puesto 3 tareas que se hace, relee los puntos qu ehe puesto más arriba. Hay gente que edita, hay gente que cataloga, ... No líes. Aunque no haya nadie editando en ese momento el contenido del que se está haciendo streaming (de hecho el contenido que se emite en web es LowRes por lo que no se edita, se edita el bruto y posteriormente se conforma). El ancho de banda es importante, al igual que son las latencias. Por eso, al usar HSM en el mundo de media, se hacen cosas como las que he mencionado y que sigues ignorando una y otra vez: - dejar el principio del contenido on-line - dejar determinadas secuencias on-line y las demás en near-line u off-line
¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber usado Youtube si quieres.
Hijo, pues no. La NBA no es una empresita del montón, la verdad.
Google tampoco ;)
Claro, pero es que si te digo que cualquier empresa del montón necesita disponer de esos datos en tiempo real (no archivados) no me crees. Por eso he puesto como ejemplo es servicio IMAP de Gmail.
No Camaleó, lo que digo es que conozco empresas que lo usan. Te he dicho que empresas como IBM, EMC y otras tienen muchos clientes que lo usan (en entornos que tu estás poniendo como ejemplo) y sigues sin creerme. Como no lo conoces, te resistes a creer que eso funciona. Pues te guste o no, te resistas o no: eso funciona y hay mucha gente usándolo. Te he puesto ejemplos de TV y productoras cuyo "tiempo real" es MUY superior al de una oficina que necesita acceso a un correo o un fax, ejemplos que has puesto tu. Abre los ojos. El que tu no lo conozcas o no lo hayas probado, no significa que no existe o que no se pueda uasr. Sale allí afuera y mira por ti misma las empresas que lo usan y para qué lo usan. Por cierto, otra cosa: correo, fax, ofimática y similares NO son tiempo real. Media (broadcast, postproducción, ...) sí es tiempo real, al igual que es el control de un avión, una central nuclear, ... Yo SÍ te he puesto ejemplo de uso de HSM en entornos de tiempo real, tu no ;)
Te he puesto como ejemplo cualquier empresa vulgaris pero tú dices que no, que eso de mantener los correos en línea no era la norma. Ahí es cuando te he puesto como ejemplo a Gmail. Podría haber dicho cualquier otra empresa que dé servicio IMAP (o en la nube).
¿Google vulgaris? Eso es nuevo: si mal no recuerdo, tienen más de 1 millón de servidores.
Es más, eGoogle puede que tengas más razón en que no puedan archivar correo, pero en una empresa pequeña/mediana que los trabajadores se van a casa ... razón de más para poder archivar, mojer y hacer lo que te da la gana: no hay nadie usándolo (bueno, siempre hay alguien conectado), pero reclama el correo, fichero, dato y solucionado. De hecho, te he puesto ejemplos en los que el usuario no sabe ni que está trabajando contra cinta.
Sigo sin ver claro eso de acceder a los correos mediante IMAP tirando de un archivo ubicado en una cinta, de verdad... como no sea un buen sistema de cinta, rápido y fiable, te echan a perder la copia en pocos días y la cinta, a la basura. ¿Tiene límites de escritura, no?
¿Qué tecnología de cinta usas? ¿DLT? No me extraña que tengas ese concepto de las cintas ;) No digo que la cintas no se estropeen, claro que se estropean, pero sigues sin entender el concepto. Para empezar, cuando archivas o usas HSM, no estás accediendo a los datos constantemente, son datos "antiguos" que a lo mejor accedes una vez al año o al mes. Así que el desgaste de la cinta no es tan grande, el consumo eléctrico tampoco, el calor producido tampoco, ... Por l oque no estás constantemente leyendo de cinta. Segundo, al mover los datos a cinta, lo haces de forma que: - sea cuando menos uso se le da (de noche, por ejemplo) - se migren la mayor cantidad de datos posible - ... Así que tampoco estás constantemente escribiendo a cinta. A todo esto, el disco también se estropea y más si no es "enterprise class".
A ver, a ver... 20 GiB son 20 GiB que necesitan espacio físico si tienes un disco duro de 60 GiB y si no tienes espacio, el sistema se queda colgado, no puedes iniciar sesión, los correos se rebotan, etc...
Correcto, de ahí que te haya hablado de: - tecnologías ue te permiten ampliar, archivar, ...
- previsiones
- montar un segundo disco y descargar datos "amanuense"
Eso jamás te lo he negado. Lo que digo es que si crece /var/algo en su propio sistema de ficheros, /var (que está en SU sistema de ficheors) NO crece de forma física.
No pillo ese "no crecimiento físico" del que hablas. Los datos ocupan espacio físico, estén en /var, en /home o en cualquier otro lado (recurso de red, servidor remoto...).
Te pongo el ejemplo que ya he puesto, imagínate que tienes (4 sistemas de ficheros, 4 particiones): /dev/sda1 -> disco de 80 GB -> / /dev/sdb1 -> disco de 80 GB -> /var /dev/sdc1 -> disco de 80 GB -> /var/correo /dev/sdd1 -> disco de 80 GB -> /var/log /dev/sde1 -> disco de 80 GB -> /home Haces hoy un df -h y te sale (ponemos sólo lo ocupado): / 3 GB /var 2 GB /var/correo 10 GB /var/log 10 GB /home 30 GB Si haces un "du -sh /var", te saldría: 2 GB + 10 Gb + 10 GB = 22 GB Resulta que en tu empresa se usa mucho el correo y mañana lo vuelves a ejecutar (df -h) y te sale: / 3 GB /var 2 GB /var/correo 50 GB /var/log 30 GB /home 30 GB Si ahora vuelves a ejecutar "du -sh /var", te mostrará: 2 GB + 50 GB + 30 GB = 82 GB. Este comando te está sumando todo lo que cuelga de /var, pero si te fijas en df ... el sistema de ficheros /var NO CRECE, crecen /var/correo y /var/log. Luego NO tienes que ampliar /var, tienes que ampliar /var/correo y /var/log. El que crece físicamente es /var/correo y /var/log. /, /home y /var no crecen físicamente, pero de forma lógica, / y /var sí crecen porque tienen sistemas de ficheros que cuelgan por debajo.
¡Claro que crecen! Hasta el límite físico que tengas definido (sea el tamaño del disco o de la partición), pero la cantidad de datos se incrementa con cada copia de seguridad que hago, o con cada correo o con cada fax que se envía o se recibe.
A ver, tú has escrito
"Pues eso... para el 85% de las "empresas/usuarios" "/var" crece
y mucho > ;-)"
Y yo he dicho que no, que lo que crece es el sistema de ficheros (mejor dicho, el volumen de datos de un sistema de ficheros) y que si /var y /var/algo son dos sistemas de ficheros diferentes y el que crece es /var/algo ... /var no crece. Y eso mismo le he respondido a Carlos.
Ah, ya, que dabas por hecho que /var/*/ está particionado.
Aún así, está limitado por el tamaño de la partición que lo contiene y los datos crecen de la misma forma. No en "/var", pero sí en "/var/ mail" (por ejemplo). Estás con el mismo problema.
NO estás con el mismo problema. /var no crece por lo que no tienes que ampliar /var. De hecho, si amplías /var ... estás desperdiciando espacio. porque /var no crece, tienes que ampliar /var/algo que es el que crece. [...]
Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE TODOS los ficheros que hay en tus sistemas informáticos se usen SIEMPRE. No me lo creo.
Necesitar != querer.
Ya te dije que sí. Al menos yo necesito tener los faxes recibidos/ enviados de hace 3 años bajo /var/spool/hylafax... o eso o empiezo a montar el servidor desde cero integrando alguna de esas soluciones que comentabas -> inviable, al menos de momento.
No es desde cero, estas soluciones se integran en lo que ya tienes ;) En cuanto a que en tu empresa usan TODOS los ficheros de fax recibidos SIEMPRE ... es físicamente imposible. Tendría que haber tantas personas como ficheros de fax ... y ya se los sabrían de memoria por lo que no necesitarían acceder a ellos ;) Te lo vuelvo a repetir quere != necesitar. Yo quiero un Rolls Royce con chófer, pero no lo necesito ;) Tu quieres tener esos ficheros on-line, pero no los necesitas on--line. Los quieres on-line porque no quieres que la gente te dé la murga pidiéndote los ficheros (fax) que se encuentran en una cinta o en un CD. Pero es que no funciona así, te lo vuelvo a repetir: - si es HSM: el usuario no sabe que está en cinta, el usuario pincha en la unidad D: (o la que sea) y ya está - si es Archivado: el usuairo abre su aplicación y reclama el fichero, igual que si se tiene que levantar físicamente e ir a un archivador a coger una factura o un plano ploteado Camaleón, hay empresas de todo tipo, tamaño y color usando estas herramientas y funcionan, te guste o no. Para gestionar sus fax, sus correos, sus ficheros de imágenes, todo lo que se te pueda ocurrir. Hay gente con más o menos correos, más o menos ficheros, más o menos empleados, ... Pero les funciona. Te lo vuelvo a repetir: sal allí afuera y habla con ellos. Como siempre, habrá gente contenta y gente descontenta, eso no te lo va a negar nadie
Eso lo dices porque no has usado sistemas de HSM, si los hubieras usado verías que no NECESITAS que estén on-line. El usuario no sabe ni dónde están ni se da cuenta si tarda en venir o no de cinta a disco. Te he puesto ejemplos de vídeo que es TIEMPO REAL, si pierdes un frame ... al carajo todo. Y allí funciona. También te he dicho que nosotros y otros fabricantes lo implementan para todo tipo de ficheros: ofimática, imágenes, ...
Estás haciendo suposiciones sobre algo que no has usado y no conoces. Yo lo he visto en clientes grandes y pequeños, con necesidades de tiempo real y no y el usuario no se da cuenta.
Hay muchas cosas que no conozco, Rafa. Lo que sí se es que implementar esas soluciones integradas que dices cuestan tiempo y dinero.
Como todo en esta vida, no hay nada gratis. Eso jamás te lo he negado ni discutido
Que sí, que están muy bien. Sólo te digo que en nuestro caso en concreto no es una opción justificable. Es más, si me dieran presupuesto, preferiría actualizar los routers, actualizar los switches de la red2 a gigabit (pasar de "10/100" a "1000" se nota... y mucho), añadir algún cortafuegos más o traer una estación de trabajo nueva. Tenemos otras prioridades antes que el almacenamiento.
Volvemos a lo de antes, es que yo no te he dicho que lo tengas que implementar. Sólo te he dicho: - que la tecnología existe - cómo funciona (a grandes rasgos) - algunos fabricnates que lo tienen - que hay clientes contentos - ejemplos de clientes En ningún momento te he dicho que lo uses. Es másm te he dicho que prefiero qu eno lo uses ni tu ni nadie porque así me hago rico vendiendo discos :D
Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo de empresa en la que trabajas y coincide con el tipo de empresa de algunos de nuestros clientes. Pero eso no quita que esté mal y no me vale el que digas: "Es que los usuarios se quejan o no quieren aprender a usar FTP".
Exacto: no quiere usar el FTP.
A tus usuarios los puedes "domesticar" (quiero decir, intentar hacerles comprender cómo hacer bien las cosas) pero a los usuarios de empresas asociadas o con las que trabajas, ah, amigo... esos no son tuyos y entienden la vida de otra forma... si te gusta vale, y si no, adiós contrato. Es así.
No es cierto y lo he vivido con clientes nuestros. Han migrado a DAM y proveedores y usuarios internos trabajan tan contentos. ¿Saben realmente que es un FTP o un WebDAV o un CIFS? No. ¿Lo tienen que saber? No. Tu le das una interfaz web o si quieres les programas un cliente nativo para su sistema operativo o un cliente XUL para Firefox o como te de la gana o creas que es más sencillo para el usuario y ya está. Generalmente lo más sencilo para el uusario es una interfaz web.
Rafa, yo no puedo controlar a nuestros proveedores ni decirles cómo tienen que hacer las cosas. Nos mandan a freír monas. Si ellos quieren enviar por e-mail lo que tengan que enviar lo hacen a su modo o como buenamente puedan/sepan (una memoria completa en PDF de un proyecto puede ocupar más que un sólo archivo de CAD con los planos o los cálculos de las estructuras) .
A ver, cada proveedor es distinto. Con unos sí podemos hacerlo (porque llevamos más tiempo trabajando con ellos, sabemos su metodología y ellos la nuestra, hemos establecido un protocolo de actuación, etc...) pero con los que tenemos poca relación, no.
A lo mejor me he explicado mal, no te estoy diciendo que lo hagas, te estoy diciendo cómo lo puedes hacer en caso de querer hacerlo.
A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que al año siguiente se archivan." Vuelves a darme la razón. Llevo todo este tiempo diciendo que se establecen políticas basadas en tiempo y el que establece ese tiempo es el cliente porque es el que sabe cómo funciona su empresa.
He dicho "un año" por decir... pueden ser 5, o 10... y el /var sigue creciendo a diario.
Me da igual. El cliente es el que establece las políticas y es el que las modifica. He comentado en otro correo que los 3 - 4 primeros meses, el cliente modifica las reglas para irlo tuneando o afinando para sus necesidades, pero a partir del 6 mes ... eso no lo vuelve a tocar nadie (a menos que los flujos de trabajo cambien).
Pero es que sigues dando por hecho que se tiene que archivar todo cada poco tiempo y yo no lo veo así.
NO señor. Yo NO doy por hecho que HAY que archivar TODO CADA POCO TIEMPO. He dicho que es el CLIENTE el que DECIDE las políticas de archivado y eso incluye lo que se archiva y cuándo se archiva. [...] Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-24 22:51, Rafa Grimán wrote:
No pillo ese "no crecimiento físico" del que hablas. Los datos ocupan espacio físico, estén en /var, en /home o en cualquier otro lado (recurso de red, servidor remoto...).
Te pongo el ejemplo que ya he puesto, imagínate que tienes (4 sistemas de ficheros, 4 particiones): /dev/sda1 -> disco de 80 GB -> / /dev/sdb1 -> disco de 80 GB -> /var /dev/sdc1 -> disco de 80 GB -> /var/correo /dev/sdd1 -> disco de 80 GB -> /var/log /dev/sde1 -> disco de 80 GB -> /home
Haces hoy un df -h y te sale (ponemos sólo lo ocupado): / 3 GB /var 2 GB /var/correo 10 GB /var/log 10 GB /home 30 GB
Pero eso es ser tiquismiquis >:-) Ya sabemos que puedes organizar la estructura como quieras, puedes tener un espacio tremendo en alguno de los subdirectorios del /var para lo que sea que sepas que crece mucho, en un disco físico clase enterprise, con LVM, RAID, HSM o lo que te de la gana, y tener el resto en un espacio más normalito. Pero es que esa no era la pregunta original... el OP tiene sólo un disco de 65 gigas y preguntaba como particionarlo, con LVM o con lógicas. En ese contexto, a la partición de /var no se le puede presuponer un tamaño fijo y pequeño. En este contexto, /var crece. Si especificas que vas a separar las partes de /var que crecen más y ponerlas en otro sitio para evitar que /var crezca (considerando estrictamente /var), es otra cosa. Pero se sale de la premisa inicial o las habituales. Claro que se puede hacer, y se hace.
Te lo vuelvo a repetir quere != necesitar. Yo quiero un Rolls Royce con chófer, pero no lo necesito ;) Tu quieres tener esos ficheros on-line, pero no los necesitas on--line. Los quieres on-line porque no quieres que la gente te dé la murga pidiéndote los ficheros (fax) que se encuentran en una cinta o en un CD. Pero es que no funciona así, te lo vuelvo a repetir:
- si es HSM: el usuario no sabe que está en cinta, el usuario pincha en la unidad D: (o la que sea) y ya está
- si es Archivado: el usuairo abre su aplicación y reclama el fichero, igual que si se tiene que levantar físicamente e ir a un archivador a coger una factura o un plano ploteado
Suponte que uno de los usuarios hace un grep sobre todos los faxes... ya la has liado, porque o se cargan todos en disco (si caben) o tienes un sistema que haga la busqueda por zonas. Y como el usuario te haya programado un script que hace tres greps paralelos, y cada uno consistente en 20 greps secuenciales, pues la has cagado. Me dirás ¿Y quien es el idiota que...? Pues yo... yo en mi trabajo hacía greps de esos en los logs de todo el año. Obviamente, si tengo un sistema de faxes en una empresa que manda y recibe cientos de faxes diarios, y de varias páginas con gráficos, y me piden que sean accesibles siempre los de todos los años (copia legal aparte), pues o pongo unos discos grandes, con backups incrementales, o pongo un sistema de esos que dices de tres capas, la ultima en cinta, con lo que los discos van a ser más pequeños. Pero eso no es rentable si el volumen de faxes en total cabe en un disco de menos de 500 gigas. Y me apuesto una pizza que los de Camaleón caben y le sobra.
No es cierto y lo he vivido con clientes nuestros. Han migrado a DAM y proveedores y usuarios internos trabajan tan contentos. ¿Saben realmente que es un FTP o un WebDAV o un CIFS? No. ¿Lo tienen que saber? No. Tu le das una interfaz web o si quieres les programas un cliente nativo para su sistema operativo o un cliente XUL para Firefox o como te de la gana o creas que es más sencillo para el usuario y ya está. Generalmente lo más sencilo para el uusario es una interfaz web.
Rafa, yo no puedo controlar a nuestros proveedores ni decirles cómo tienen que hacer las cosas. Nos mandan a freír monas. Si ellos quieren enviar por e-mail lo que tengan que enviar lo hacen a su modo o como buenamente puedan/sepan (una memoria completa en PDF de un proyecto puede ocupar más que un sólo archivo de CAD con los planos o los cálculos de las estructuras) .
A ver, cada proveedor es distinto. Con unos sí podemos hacerlo (porque llevamos más tiempo trabajando con ellos, sabemos su metodología y ellos la nuestra, hemos establecido un protocolo de actuación, etc...) pero con los que tenemos poca relación, no.
A lo mejor me he explicado mal, no te estoy diciendo que lo hagas, te estoy diciendo cómo lo puedes hacer en caso de querer hacerlo.
Yo lo que haría sería poner dos servidores de correo, uno "normal", y otro para los enormes, con baja prioridad. Si envias uno muy grande al principal, que rebote. Me sospecho que podría ser automático. O bien, en el interior de la empresa, los distribuiría en dos servidores imap distintos, para evitar que el servidor habitual se vuelva horriblemente lento. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvTj/4ACgkQU92UU+smfQVQiQCfX8KvLVQrGBiAPuUv2qo7c2tf 9HgAoICnPjVXyIzrUvihmr0VHNY2mP2/ =fjqE -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Sunday 25 April 2010 02:42 Carlos E. R. wrote
On 2010-04-24 22:51, Rafa Grimán wrote:
No pillo ese "no crecimiento físico" del que hablas. Los datos ocupan espacio físico, estén en /var, en /home o en cualquier otro lado (recurso de red, servidor remoto...).
Te pongo el ejemplo que ya he puesto, imagínate que tienes (4 sistemas de
ficheros, 4 particiones): /dev/sda1 -> disco de 80 GB -> / /dev/sdb1 -> disco de 80 GB -> /var /dev/sdc1 -> disco de 80 GB -> /var/correo /dev/sdd1 -> disco de 80 GB -> /var/log /dev/sde1 -> disco de 80 GB -> /home
Haces hoy un df -h y te sale (ponemos sólo lo ocupado): / 3 GB /var 2 GB /var/correo 10 GB /var/log 10 GB /home 30 GB
Pero eso es ser tiquismiquis >:-)
No es ser tiquismiquis, es ser realista ;)
Ya sabemos que puedes organizar la estructura como quieras, puedes tener un espacio tremendo en alguno de los subdirectorios del /var para lo que sea que sepas que crece mucho, en un disco físico clase enterprise, con LVM, RAID, HSM o lo que te de la gana, y tener el resto en un espacio más normalito.
Pero es que esa no era la pregunta original... el OP tiene sólo un disco de 65 gigas y preguntaba como particionarlo, con LVM o con lógicas. En ese contexto, a la partición de /var no se le puede presuponer un tamaño fijo y pequeño. En este contexto, /var crece. Si especificas que vas a separar las partes de /var que crecen más y ponerlas en otro sitio para evitar que /var crezca (considerando estrictamente /var), es otra cosa. Pero se sale de la premisa inicial o las habituales. Claro que se puede hacer, y se hace.
Pero es que yo ya contesté a su pregunta, lo que estaba haciendo era aclarar que tenemos que tener en cuenta la disposición física y que no necesariamente parte lógica = parte física. Si no tenemos eso en cuenta ... la podemos liar ;)
Te lo vuelvo a repetir quere != necesitar. Yo quiero un Rolls Royce con chófer, pero no lo necesito ;) Tu quieres tener esos ficheros on-line, pero no los necesitas on--line. Los quieres on-line porque no quieres que la gente te dé la murga pidiéndote los ficheros (fax) que se encuentran en una cinta o en
un CD. Pero es que no funciona así, te lo vuelvo a repetir: - si es HSM: el usuario no sabe que está en cinta, el usuario pincha
en la unidad D: (o la que sea) y ya está
- si es Archivado: el usuairo abre su aplicación y reclama el fichero,
igual que si se tiene que levantar físicamente e ir a un archivador
a coger una factura o un plano ploteado
Suponte que uno de los usuarios hace un grep sobre todos los faxes... ya la has liado, porque o se cargan todos en disco (si caben) o tienes un sistema que haga la busqueda por zonas. Y como el usuario te haya programado un script que hace tres greps paralelos, y cada uno consistente en 20 greps secuenciales, pues la has cagado.
¿Cuántos usuarios saben que grep existe? ;)
Me dirás ¿Y quien es el idiota que...? Pues yo... yo en mi trabajo hacía greps de esos en los logs de todo el año.
Ya me has dado parte de una política: 1 año ;) La cosa es saber cuáles son los flujos de trabajo. Si no conocemos nuestra empresa ni cómo trabaja la gente ... mal vamos porque no seremos capaces de: - dimensionar hardware - hacer un cálculo de presupuestos para el año siguiente - hacer previsiones de crecimiento - hacer frente a situaciones inesperadas - ...
Obviamente, si tengo un sistema de faxes en una empresa que manda y recibe cientos de faxes diarios, y de varias páginas con gráficos, y me piden que sean accesibles siempre los de todos los años (copia legal aparte), pues o pongo unos discos grandes, con backups incrementales, o pongo un sistema de esos que dices de tres capas, la ultima en cinta, con lo que los discos van a ser más pequeños.
Esa es la idea.
Pero eso no es rentable si el volumen de faxes en total cabe en un disco de menos de 500 gigas. Y me apuesto una pizza que los de Camaleón caben y le sobra.
Y dale ... Que yo no le estoy intentando convencer que tiene que usarlo. Yo no he dicho en ningún momento que Camaleón (o cualquier otro lector de esta lista) lo tenga que implementar. Qué perra habéis cogido! Que me da igual que lo implemente o no, que no esa no es mi "misión". Me he limitado a comentaros una tecnología que existe y os habéis empeñado en que quiero que todo el mundo lo use. No sé de dónde habéis sacado esa idea. Si claramente he dicho, copio y pego: "En ningún momento te he dicho que lo uses. Es másm te he dicho que prefiero qu eno lo uses ni tu ni nadie porque así me hago rico vendiendo discos :D" Otra cosa que no tenéis en cuenta es que os estáis obsesionando única y exclusivamente con los fax y los crreos. Ya sí, era un ejemplo, pero estáis suponiendo un único tipo de fichero no el almacenamiento como un todo, lo cual es un error porque tu empresa almacena más que faxes y el volumen total de tu almacenamiento es lo que te (tiene que) preocupa(r). Una empresa NO monta esto SÓLO para gestionar un tipo de fichero. Es decir, aunque tus 27 años de fax quepan en un disco de 80 GB, estas soluciones NO se implementan SÓLO para el fax sino para todos los ficheros: PDFs, DOCs, PPTs, XLSs, XDGs, JPGs, AVIs, MOVs, AIFFs, ... Las tecnologías de las que he hablado son para gestionar ALMACENAMIENTO, como un todo, NO son para gestionar un único tipo de fichero. Y, de hecho, tenemos clientes que usan esta tecnología para su almacenamiento, pero excluyen un determinado tipo de fichero o sistema de ficheros poruqe no crece. También se os está escapando que estoy hablando de POLÍTICAS de migración: - por fecha - por tamaño - por usuario - por tag (puedes ponerle un tag a los ficheros) - ... - incluso los puedes mover manualmente, como os he dicho en correos anteriores, bien sea el admin, bien sea el usuario ... Eso es otra política: si queremos que el usuario pueda o no migrar lo datos [...]
A lo mejor me he explicado mal, no te estoy diciendo que lo hagas, te estoy diciendo cómo lo puedes hacer en caso de querer hacerlo.
Yo lo que haría sería poner dos servidores de correo, uno "normal", y otro para los enormes, con baja prioridad. Si envias uno muy grande al principal, que rebote. Me sospecho que podría ser automático.
O bien, en el interior de la empresa, los distribuiría en dos servidores imap distintos, para evitar que el servidor habitual se vuelva horriblemente lento.
Es otra opción. Cada maestrillo tiene su librillo ;) Hay muchas alternativas :) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-24 22:51, Rafa Grimán wrote:
Hola :)
Por cierto, otra cosa: correo, fax, ofimática y similares NO son tiempo real. Media (broadcast, postproducción, ...) sí es tiempo real, al igual que es el control de un avión, una central nuclear, ... Yo SÍ te he puesto ejemplo de uso de HSM en entornos de tiempo real, tu no ;)
En realidad, la tele no es tiempo real, o no necesariamente. El control de un avión, pues sí, una buena parte. No todo. Pero es que incluso la lectura del teclado puede ser tiempo real. El caso es que un programa en tiempo real no significa que tenga que tener un un tiempo de respuesta de microsegundos. ¡En realidad pueden ser horas! EL concepto de "tiempo real" lo que significa es simplemente que se garantiza respuesta en un tiempo determinado o menor de un limite. El limite pueden ser minutos, segundos, o milisegundos. Así, para el montaje de una película, te da igual que te venga el vídeo en una centésima de segundo o en unas cuantas décimas: llegará cuando llegue, simplemente saldrá retrasado. En cambio, si lo que controlas es la posición del timón de una aeronave no te puedes permitir que el ordenador se quede pensando en un bucle sin saber que valor poner. Tiene que responder _ya_. Si quieres, puedes pagar para que lo del vídeo responda en tiempo real, pero te costará una pasta. No basta con que responda rápido, no es eso. Tienes que garantizar un tiempo de respuesta. Y si está en una cinta, y al final de la misma... pues no puedes garantizar un tiempo de respuesta en todos los casos de milisegundos. Responderá rápido, pero no tanto. Es que se confunde "tiempo real" con "respuesta muy rápida". No es lo mismo. Puede ser un sistema de respuesta muy rápida, por ejemplo con una media de 1 mS, con variaciones típicas de hasta 5 mS. Pero basta con que una sóla vez tarde 1S en responder para que ya no sea "tiempo real". En cambio, si garantizas que siempre responderá en menos de dos segundos, y eso se cumple, pues tienes un sistema de tiempo real de dos segundos. Por ejemplo, un termostato doméstico hecho con un microcontrolador, que apaga la calefacción cuando la temperatura baja medio grado de la programada, con diversos periodos de calor o frío según dia de la semana y hora, que hace sólo una medida de temperatura cada minuto para ahorrar pilas, es un sistema a tiempo real con respuesta de un minuto o menor. Incluso en los sistemas de tiempo real verdadero, sólo una parte es tiempo real. Poquito. Es muy, pero muy caro, de programar. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvTkAQACgkQU92UU+smfQXJSACgjuRaDjnGLi07OiIe8btLbrft oYAAoId9h3njcvADat2mp7DhVAMrjRgI =26b8 -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 02:42:44 Carlos E. R. escribió:
Incluso en los sistemas de tiempo real verdadero, sólo una parte es tiempo real. Poquito. Es muy, pero muy caro, de programar.
Tampoco hay para tanto, es mas complicado de programar y mas aun de debugar y probar, pero, yo diria que multiplica el precio por tres mas o menos. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-25 06:44, Lluis wrote:
On Domingo, 25 de Abril de 2010 02:42:44 Carlos E. R. escribió:
Incluso en los sistemas de tiempo real verdadero, sólo una parte es tiempo real. Poquito. Es muy, pero muy caro, de programar.
Tampoco hay para tanto, es mas complicado de programar y mas aun de debugar y probar, pero, yo diria que multiplica el precio por tres mas o menos.
La 5ESS usa un unix de tiempo real. Cualquier modificación costaba millones. Si es verdadero tiempo real cuesta una pasta, porque tienes que garantizar un tiempo de respuesta. No es responder muy rápido, sino garantizar una respuesta, y antes de un tiempo dado, y las garantías son muy caras en este negocio donde nunca se garantiza nada. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvUMekACgkQU92UU+smfQX3AgCgkFcdxoEwbQ86/QOkVk9OBxgS dOEAn1kmdtSUfSF7LUWtbxPBqgSca7L1 =4y7P -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 14:13:29 Carlos E. R. escribió:
On 2010-04-25 06:44, Lluis wrote:
On Domingo, 25 de Abril de 2010 02:42:44 Carlos E. R. escribió:
Incluso en los sistemas de tiempo real verdadero, sólo una parte es tiempo real. Poquito. Es muy, pero muy caro, de programar.
Tampoco hay para tanto, es mas complicado de programar y mas aun de debugar y probar, pero, yo diria que multiplica el precio por tres mas o menos.
La 5ESS usa un unix de tiempo real. Cualquier modificación costaba millones.
Si es verdadero tiempo real cuesta una pasta, porque tienes que garantizar un tiempo de respuesta. No es responder muy rápido, sino garantizar una respuesta, y antes de un tiempo dado, y las garantías son muy caras en este negocio donde nunca se garantiza nada.
Vale... Se garantiza un tiempo de respuesta, interrupciones y demas.... Que alguien cobre millones, como bien sabemos, solo depende de que haya un tonto dispuesto a pagarlos. Yo, solo hablo desde el perfil tecnico. Y algun RTOS he hecho para un 68000 -- Saludos Lluis
Hola :) On Sunday 25 April 2010 02:42 Carlos E. R. wrote
On 2010-04-24 22:51, Rafa Grimán wrote:
Hola :)
Por cierto, otra cosa: correo, fax, ofimática y similares NO son tiempo real. Media (broadcast, postproducción, ...) sí es tiempo real, al igual que es el control de un avión, una central nuclear, ... Yo SÍ te he puesto ejemplo de uso de HSM en entornos de tiempo real, tu no ;)
En realidad, la tele no es tiempo real, o no necesariamente. El control de un avión, pues sí, una buena parte. No todo. Pero es que incluso la lectura del teclado puede ser tiempo real.
Si es un noticiario, sí es tiempo real ;) Y creeme, estar en una TV y ver la que se lía cuando emiten un noticiario ... eso es más rápido que tiempo real y me refiero a los trabajadores ;)
El caso es que un programa en tiempo real no significa que tenga que tener un un tiempo de respuesta de microsegundos. ¡En realidad pueden ser horas! EL concepto de "tiempo real" lo que significa es simplemente que se garantiza respuesta en un tiempo determinado o menor de un limite. El limite pueden ser minutos, segundos, o milisegundos.
Efectivamente, la emisión de un noticiario necesita un tiempo de respuesta por parte de los trabajadores como por parte del equipamiento informático ;) Otro ejemplo es un partido de fútbol o de baloncesto. ¿Te imaginas que el partido NO se transmitiera en tiempo real? Con lo futboleros que son los españoles (yo no) ... se iba a liar una buena.
Así, para el montaje de una película, te da igual que te venga el vídeo en una centésima de segundo o en unas cuantas décimas: llegará cuando llegue, simplemente saldrá retrasado. En cambio, si lo que controlas es la posición del timón de una aeronave no te puedes permitir que el ordenador se quede pensando en un bucle sin saber que valor poner. Tiene que responder _ya_.
No señor. En las TVs no se acepta que un frame venga con "retraso". Otra cosa es que eso ocurra. Cuando estás montando una TV digital, las pruebas que se hacen para ver si hay caídas de frames son muy interesantes. Hasta tal punto que se miden rendimientos en: - cabina de discos - switches de fibra - servidor - switches Ethernet - estaciones de trabajo Y todo simultáneamente. Te lo garantizo porque me ha tocado ;) Tampoco estás teniendo en cuenta que estés recibiendo una ingesta de Afganistán y al mismo tiempo estás emitiendo (playout) de la última rueda de prensa de Zapatero y ... En el cine es casi peor. Ahora muchas películas se graban y editan en 4K en las que un frame puede ocupar 50 MBytes y son 24 fps ... 1200 MBytes/s. Si no garantizas ese rendimiento ... pierdes frames y es inaceptable. Por cierto, no te hablo de picos de 1200 MBytes/s sino sostenido. Es decir, puedes tener horas de metraje y tienes que garantizar esos 1200 MBytes/s en todo momento.
Si quieres, puedes pagar para que lo del vídeo responda en tiempo real, pero te costará una pasta. No basta con que responda rápido, no es eso. Tienes que garantizar un tiempo de respuesta. Y si está en una cinta, y al final de la misma... pues no puedes garantizar un tiempo de respuesta en todos los casos de milisegundos. Responderá rápido, pero no tanto.
Mal, está spensando sólo en películas. Una TV hace más que eso ;)
Es que se confunde "tiempo real" con "respuesta muy rápida". No es lo mismo.
Ya lo sé. Podía haber puesto el ejemplo de simuladores de vuelo, tanques y camiones que tenemos, pero son jeemplos menos conocidos ;) Y te repito, el ejemplo de pelis que has puesto no es tiempo real, lo sé, pero es que no sólo de pelis vive la TV ;)
Puede ser un sistema de respuesta muy rápida, por ejemplo con una media de 1 mS, con variaciones típicas de hasta 5 mS. Pero basta con que una sóla vez tarde 1S en responder para que ya no sea "tiempo real". En cambio, si garantizas que siempre responderá en menos de dos segundos, y eso se cumple, pues tienes un sistema de tiempo real de dos segundos.
Por ejemplo, un termostato doméstico hecho con un microcontrolador, que apaga la calefacción cuando la temperatura baja medio grado de la programada, con diversos periodos de calor o frío según dia de la semana y hora, que hace sólo una medida de temperatura cada minuto para ahorrar pilas, es un sistema a tiempo real con respuesta de un minuto o menor.
Incluso en los sistemas de tiempo real verdadero, sólo una parte es tiempo real. Poquito. Es muy, pero muy caro, de programar.
Ya, te pongo el ejemplo de los simuladores. En un simulador de vuelo (aviones de combate) necesitas GARANTIZAR el tiempo de respuesta, tiempo real, ... porque si te falla un frame, el piloto puede reaccionar cuando en la vida real el misíl no se "para"/"congela". En un simulador NO te puedes permitir que el misíl se "congele" en el aire o que el simulador responda más tarde a la instrucción del piloto. En la TV ocurre algo similar: no te puedes permitir que en la transmisión de la apertura de las olimpiadas se pierdan frames o se "congele" la imagen. Tampoco te puedes permitir este tipo de cosas en un Real Madrid - Barça. Ya, ya sé que pasa, igual que pasa que en una central nuclear (otro ejemplo que he puesto de tiempo real) haya fallos (tengo un amigo que ha trabajado en una central nuclear) o que falle en aviones o en trenes o en ... Eso no siginifca que el sistema no sea tiempo real. Se ha diseñado como tal ... pero a lo mejor se ha caido un repetidor o se ha caído un disco o un DIMM de memoria ha fallado, ... Como siempre, hay fallos: somos Humanos (imperfectos) y vivimos en un entorno caótico ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 12:55:35 Rafa Grimán escribió:
Ya, ya sé que pasa, igual que pasa que en una central nuclear (otro ejemplo que he puesto de tiempo real) haya fallos (tengo un amigo que ha trabajado en una central nuclear) o que falle en aviones o en trenes o en ... Eso no siginifca que el sistema no sea tiempo real. Se ha diseñado como tal ... pero a lo mejor se ha caido un repetidor o se ha caído un disco o un DIMM de memoria ha fallado, ...
Al menos, en trenes, no pasara, o no deberia pasar. Los sistemas SIL4 no dependen de un DIMM -- Saludos Lluis
Hola :) On Sunday 25 April 2010 16:49 Lluis wrote
On Domingo, 25 de Abril de 2010 12:55:35 Rafa Grimán escribió:
Ya, ya sé que pasa, igual que pasa que en una central nuclear (otro ejemplo que he puesto de tiempo real) haya fallos (tengo un amigo que ha trabajado
en una central nuclear) o que falle en aviones o en trenes o en ... Eso no siginifca que el sistema no sea tiempo real. Se ha diseñado como tal ... pero a lo mejor se ha caido un repetidor o se ha caído un disco o un DIMM de memoria ha fallado, ...
Al menos, en trenes, no pasara, o no deberia pasar. Los sistemas SIL4 no dependen de un DIMM
Cierto 0:) A lo que me refería es que aunque diseñemos el tiempo real y lo programemos perfectamente, siempre hay algo que puede fallar :( Pero eso no significa que no sea tiempo real. Gracias por la corrección de lo de los DIMMs ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo.
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente. No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkvR910ACgkQtTMYHG2NR9VvpgCfaFWhI8gzl9gYoXXbKa3yqFJ8 focAn3k8XTblfwXJ4auvp8jIRZmqZTQU =JWm0 -----END PGP SIGNATURE-----
Hola :) On Friday 23 April 2010 21:39 Carlos E. R. wrote
Content-ID:
El 2010-04-23 a las 13:32 +0200, Rafa Grimán escribió:
...
Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo.
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente.
No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta.
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son. Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión. Lo de core y socket no me lo acabo de inventar. En muchos concursos he visto usar indistintamente core y socket y procesador. Te dicen que quieren 128 cores y reulta que lo que quieren son 128 sockets. Dependiendo del fabricnate y modelo: - AMD com Magnycours y sus 12 cores = 12 * 128 = 1536 cores - Intel con Westmere y sus 6 cores= 6 * 128 = 768 cores No sólo te cambia el número de cores sino el ancho de banda a memoria y el rendimiento de la aplicación si depende de dicho ancho de banda. También te cambia el precio, el consumo, ... Si se han inventado términos para definir determinadas cosas ... lo más lógico es usarlos para evitar confusiones ;) MHO Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sat, 24 Apr 2010 22:59:17 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 21:39 Carlos E. R. wrote
Content-ID:
El 2010-04-23 a las 13:32 +0200, Rafa Grimán escribió:
...
Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo.
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente.
No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta.
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son.
El lenguaje nada tiene que ver con el mundo del almacenamiento :-)
Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión.
No Rafa, no es tan sencillo. No puedes ignorar las normas de un idioma sólo "porque no te conviene" o "porque lía a tus clientes/proveedores". Para traducir openSUSE tuvimos que llegar a un consenso por razones lógicas y razonadas (hay palabras que no se usan en todos los países donde se habla español). Es decir, "forzamos" el uso de una palabra en concreto porque tenemos que usar un español neutro. Pero al hacerlo no nos saltamos ninguna normativa de la RAE. Lo que es "artificial" es cambiar/forzar el uso de una palabra en español sólo porque el término en inglés usa dos vocablos distintos pero en español el mismo término admite varias acepciones que sirven además para ambas. Al hacer eso estás "adulterando" el idioma sin ninguna base lingüística ni de ninguna otra índole. (...)
Si se han inventado términos para definir determinadas cosas ... lo más lógico es usarlos para evitar confusiones ;)
Exacto, el problema es saber usarlos de la forma correcta, no al "tún- tún" ni creando "paralelismos" inexistentes :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Sunday 25 April 2010 01:27 Camaleón wrote
El Sat, 24 Apr 2010 22:59:17 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 21:39 Carlos E. R. wrote
Content-ID:
El 2010-04-23 a las 13:32 +0200, Rafa Grimán escribió:
...
Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo.
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente.
No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta.
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son.
El lenguaje nada tiene que ver con el mundo del almacenamiento :-)
¿Y cómo nos comunicamos? ;)
Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión.
No Rafa, no es tan sencillo. No puedes ignorar las normas de un idioma sólo "porque no te conviene" o "porque lía a tus clientes/proveedores".
Perdona, pero los términos definieron esos proveedores/fabricantes mucho antes de que los usuarios lo hicieran ;)
Para traducir openSUSE tuvimos que llegar a un consenso por razones lógicas y razonadas (hay palabras que no se usan en todos los países donde se habla español). Es decir, "forzamos" el uso de una palabra en concreto porque tenemos que usar un español neutro. Pero al hacerlo no nos saltamos ninguna normativa de la RAE.
No he dicho que os saltéis la normativa de la RAE.
Lo que es "artificial" es cambiar/forzar el uso de una palabra en español sólo porque el término en inglés usa dos vocablos distintos pero en español el mismo término admite varias acepciones que sirven además para ambas. Al hacer eso estás "adulterando" el idioma sin ninguna base lingüística ni de ninguna otra índole.
No señor, no es en inglés, en castellano también existía esa distinción.
(...)
Si se han inventado términos para definir determinadas cosas ... lo más lógico es usarlos para evitar confusiones ;)
Exacto, el problema es saber usarlos de la forma correcta, no al "tún- tún" ni creando "paralelismos" inexistentes :-)
Es que en el mundo del almacenamiento se tenía ya definido una cosa y la otra y el que ha usado al "tun tun" esos términos ha sido el usuario cuando ha tenido acceso a un PC. Por cierto, no ha sdicho nada al respecto del ejemplo que he puesto de cores y sockets ;) Y no me puedes decir que no lleve a confusión. Por cierto, también he visto en concursos públicos confundir nodos de cálculo con cores y sockets. Si ves en un concurso público que quieren 2048 nodos de cálculo, lo primero que le preguntas al cliente es: ¿cuántos sockets en cada nodo? Pues resulta que el cliente lo que quería era 2048 cores. Eso puede ir en 128 nodos de cálculo o en una máquina Altix 4700 de SGI. Ya tenemos confusión ;) En el tema archivo y fichero puede ocurrir lo mismo: no es lo mismo tener 50000 ficheros que tener 50000 archivos. Si tienes 50000 archivos y cada uno tiene 10000 ficheros ... realmente, cuando restaures, vas a tener 500000000 ficheros. El rendimiento es diferente, el volumen de datos es diferente en el caso de que los tengas comprimidos y/o deduped, el número de i-nodos ocupados es diferente, ... Así que no, no es lo mismo. Existe esa distición por algo. Y no es el mundo del almacenamiento el que ha decidido al "tun tun", es el usuario. Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sun, 25 Apr 2010 13:08:34 +0200, Rafa Grimán escribió:
On Sunday 25 April 2010 01:27 Camaleón wrote
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son.
El lenguaje nada tiene que ver con el mundo del almacenamiento :-)
¿Y cómo nos comunicamos? ;)
Pues "hablando bien" y usando los términos correctos... no los que a los fabricantes les parezca. El idioma no lo crean ni lo desarrollan ni lo definen los fabricantes o los sectores de las industrias sino los académicos y catedráticos de la lengua, es decir, los que se suponen que saben de eso :-)
Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión.
No Rafa, no es tan sencillo. No puedes ignorar las normas de un idioma sólo "porque no te conviene" o "porque lía a tus clientes/proveedores".
Perdona, pero los términos definieron esos proveedores/fabricantes mucho antes de que los usuarios lo hicieran ;)
No, estás en un error. Aquí no se trata de "usuarios" sino de la RAE. Y el idioma español lleva ventaja (en cuanto a tiempo) a cualquier fabricante o proveedor de informática.
Para traducir openSUSE tuvimos que llegar a un consenso por razones lógicas y razonadas (hay palabras que no se usan en todos los países donde se habla español). Es decir, "forzamos" el uso de una palabra en concreto porque tenemos que usar un español neutro. Pero al hacerlo no nos saltamos ninguna normativa de la RAE.
No he dicho que os saltéis la normativa de la RAE.
Es lo tendríamos que hacer si seguimos tu sugerencia. Y de hecho lo tenemos que hacer con otras palabras. Por ejemplo, no se usa el término "ordenador" bajo ningún concepto, tenemos que seguir el español neutro y en este caso "forzamos" la utilización de otra palabra. Eso sería totalmente "artificial" si la traducción fuera "es_ES" pero ene ste caso no lo es y tenemos que seguir las normas.
Lo que es "artificial" es cambiar/forzar el uso de una palabra en español sólo porque el término en inglés usa dos vocablos distintos pero en español el mismo término admite varias acepciones que sirven además para ambas. Al hacer eso estás "adulterando" el idioma sin ninguna base lingüística ni de ninguna otra índole.
No señor, no es en inglés, en castellano también existía esa distinción.
Dame datos sobre esa afirmación porque la desconozco. Pero que sean datos contrastados y de fuentes válidas, como la RAE o algún diccionario informático especializado.
Si se han inventado términos para definir determinadas cosas ... lo más lógico es usarlos para evitar confusiones ;)
Exacto, el problema es saber usarlos de la forma correcta, no al "tún- tún" ni creando "paralelismos" inexistentes :-)
Es que en el mundo del almacenamiento se tenía ya definido una cosa y la otra y el que ha usado al "tun tun" esos términos ha sido el usuario cuando ha tenido acceso a un PC.
Y ese "mundo del almacenamiento" ¿qué tipo de validez contrastada, qué "credibilidad" tiene como para determinar qué término usar y cuál no? Es decir, ¿estamos hablando de académicos de la lengua, lingüistas, traductores, filólogos... o de gente cuyo campo NO es el lenguaje o el idioma? Por eso digo que usar un término para una cosa (file -> fichero) y otro para otra (archive -> archivo) es algo "forzado" porque el idioma español no hace esa distinción. Digo "el idioma", no los "usuarios", es decir, yo hablo de las normas que ha definido la RAE, no de cómo hablan los usuarios en la calle. Los usuarios de la calle suelen decir muchas barbaridades O:-)
Por cierto, no ha sdicho nada al respecto del ejemplo que he puesto de cores y sockets ;) Y no me puedes decir que no lleve a confusión.
La confusión entre "core" y "socket" también existe en inglés. Es decir, creo que se trata de un problema de conceptos pero no de idioma ni de traducciones. "Core" yo lo traduciría como "núcleo" y "socket" como "zócalo". Que la gente confundamos los núcleos lógicos con los zócalos físicos pues es otro cantar. Y si añadimos los "threads" (hilos) pues peor aún >:-)
Por cierto, también he visto en concursos públicos confundir nodos de cálculo con cores y sockets. Si ves en un concurso público que quieren 2048 nodos de cálculo, lo primero que le preguntas al cliente es: ¿cuántos sockets en cada nodo? Pues resulta que el cliente lo que quería era 2048 cores. Eso puede ir en 128 nodos de cálculo o en una máquina Altix 4700 de SGI. Ya tenemos confusión ;)
Pero te sigo diciendo que es una confusión "conceptual" no de traducciones correctas o incorrectas.
En el tema archivo y fichero puede ocurrir lo mismo: no es lo mismo tener 50000 ficheros que tener 50000 archivos. Si tienes 50000 archivos y cada uno tiene 10000 ficheros ... realmente, cuando restaures, vas a tener 500000000 ficheros. El rendimiento es diferente, el volumen de datos es diferente en el caso de que los tengas comprimidos y/o deduped, el número de i-nodos ocupados es diferente, ... Así que no, no es lo mismo. Existe esa distición por algo. Y no es el mundo del almacenamiento el que ha decidido al "tun tun", es el usuario.
Que sí, que no es lo mismo, pero en español la diferenciación entre uno y otro no la puedes aportar usando sólo una palabra, tienes que desarrollar la idea. En inglés, sí (el término define el concepto unívocamente), en español no (existen varias acepciones para el mismo término y además se tratan como sinónimos). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 13:38:02 Camaleón escribió:
El idioma no lo crean ni lo desarrollan ni lo definen los fabricantes o los sectores de las industrias sino los académicos y catedráticos de la lengua, es decir, los que se suponen que saben de eso :-)
Sorry, Error El idioma no lo definen loa academicos, ni los catedraticos, ni otros santos gurus. El idioma se define popr lo que habla la gente, tu y yo....... El resto es academicismo y falacia. En mi pueblo, aun no han conseguido que nadie que no busque una subvencion le llame al hardware maquinari... Es.. que quizas es mas importante entendernos que ser puristas. -- Saludos Lluis
El Sun, 25 Apr 2010 16:54:53 +0200, Lluis escribió:
On Domingo, 25 de Abril de 2010 13:38:02 Camaleón escribió:
El idioma no lo crean ni lo desarrollan ni lo definen los fabricantes o los sectores de las industrias sino los académicos y catedráticos de la lengua, es decir, los que se suponen que saben de eso :-)
Sorry, Error El idioma no lo definen loa academicos, ni los catedraticos, ni otros santos gurus.
El idioma se define popr lo que habla la gente, tu y yo.......
"Does not compute" Ni tú ni yo sabemos del tema, no podemos definir las normas sin saber de qué estamos hablando porque seguramente diremos alguna salvajada o pretenderemos crear alguna regla que sea ridícula.
El resto es academicismo y falacia.
El "resto" es darle importancia a lo que lo tiene. Las "normas" no sólo se aplican y se acatan en las matemáticas >:-) Sin normativa no hay estructura y sin estructura sólo hay caos. Y no estoy hablando de la ciencia sino del lenguaje.
En mi pueblo, aun no han conseguido que nadie que no busque una subvencion le llame al hardware maquinari...
Es.. que quizas es mas importante entendernos que ser puristas.
Hay quien pretende hacer del idioma una especie de "gazpacho" a su gusto. Yo, desde luego, no (además, no me gusta el gazpacho :-P). La misma importancia (y el mismo interés) que le pueda dar a un SIL/AENOR/IEEE/IEC se la doy las reglas de ortografía. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 17:05:43 Camaleón escribió:
El Sun, 25 Apr 2010 16:54:53 +0200, Lluis escribió:
On Domingo, 25 de Abril de 2010 13:38:02 Camaleón escribió:
El idioma no lo crean ni lo desarrollan ni lo definen los fabricantes o los sectores de las industrias sino los académicos y catedráticos de la lengua, es decir, los que se suponen que saben de eso :-)
Sorry, Error El idioma no lo definen loa academicos, ni los catedraticos, ni otros santos gurus.
El idioma se define popr lo que habla la gente, tu y yo.......
"Does not compute"
Ni tú ni yo sabemos del tema, no podemos definir las normas sin saber de qué estamos hablando porque seguramente diremos alguna salvajada o pretenderemos crear alguna regla que sea ridícula.
Bien, yo se muy bien como hablo y lo que quiero decir.
El resto es academicismo y falacia.
El "resto" es darle importancia a lo que lo tiene. Las "normas" no sólo se aplican y se acatan en las matemáticas >:-)
Es que no son matematicas, en este caso, como en otros muchos... las ciencias solo son una triste interpretación de la realidad.
Sin normativa no hay estructura y sin estructura sólo hay caos. Y no estoy hablando de la ciencia sino del lenguaje.
El caos, mientras la comunicación real exista es una opción como cualquier otra.
En mi pueblo, aun no han conseguido que nadie que no busque una subvencion le llame al hardware maquinari...
Es.. que quizas es mas importante entendernos que ser puristas.
Hay quien pretende hacer del idioma una especie de "gazpacho" a su gusto. Yo, desde luego, no (además, no me gusta el gazpacho :-P). La misma importancia (y el mismo interés) que le pueda dar a un SIL/AENOR/IEEE/IEC se la doy las reglas de ortografía.
Mira, hay una diferencia importante en el origen de las cosas. Los pueblos, hablan siempre una mezcla de lo que hablan los pueblos cercanos. Si haces un viajecito digamos de Roma( que de alguna manera fue el origen), a Madrid, veras como el lenguaje, solo cambia despacio, siempre la gente es capaz de entender al que esta cerca. Si debo ser logico, me da igual estas magnificas normas de la RAE o del IEC, lo importante al menos para mi es poder comunicarme, en castellano, en catlan, en spanglish. en catanglish o como sea. El resto, son historias de cuando se viajaba en carreta. No es lo mismo saber como hay que hacer las cosas, que saber como hay que explicarlas... Hay alguna diferencia.. algo parecido al QUE y al COMO -- Saludos Lluis
El Sun, 25 Apr 2010 17:23:02 +0200, Lluis escribió:
On Domingo, 25 de Abril de 2010 17:05:43 Camaleón escribió:
El idioma se define popr lo que habla la gente, tu y yo.......
"Does not compute"
Ni tú ni yo sabemos del tema, no podemos definir las normas sin saber de qué estamos hablando porque seguramente diremos alguna salvajada o pretenderemos crear alguna regla que sea ridícula.
Bien, yo se muy bien como hablo y lo que quiero decir.
Entonces tendrás sólo "monólogos" contigo mismo, porque si "sólo" aplicas tus normas "sólo" te entenderás tú mismo :-)
El resto es academicismo y falacia.
El "resto" es darle importancia a lo que lo tiene. Las "normas" no sólo se aplican y se acatan en las matemáticas >:-)
Es que no son matematicas, en este caso, como en otros muchos... las ciencias solo son una triste interpretación de la realidad.
Y las reglas del lenguaje también, pero son necesarias para poder al menos intentar interpretar esa "supuesta" realidad.
Sin normativa no hay estructura y sin estructura sólo hay caos. Y no estoy hablando de la ciencia sino del lenguaje.
El caos, mientras la comunicación real exista es una opción como cualquier otra.
Pero no es una opción práctica.
Es.. que quizas es mas importante entendernos que ser puristas.
Hay quien pretende hacer del idioma una especie de "gazpacho" a su gusto. Yo, desde luego, no (además, no me gusta el gazpacho :-P). La misma importancia (y el mismo interés) que le pueda dar a un SIL/AENOR/IEEE/IEC se la doy las reglas de ortografía.
Mira, hay una diferencia importante en el origen de las cosas.
Los pueblos, hablan siempre una mezcla de lo que hablan los pueblos cercanos.
Si haces un viajecito digamos de Roma( que de alguna manera fue el origen), a Madrid, veras como el lenguaje, solo cambia despacio, siempre la gente es capaz de entender al que esta cerca.
Si debo ser logico, me da igual estas magnificas normas de la RAE o del IEC, lo importante al menos para mi es poder comunicarme, en castellano, en catlan, en spanglish. en catanglish o como sea.
Sí, pero si puedo elegir entre hablar bien o hablar mal prefiero hacerlo bien. No me refiero a cuando tengo una conversación normal y cotidiana con la gente, hablo de una traducción. En una traducción existen otras necesidades y no tengo esa "flexibilidad" de la que pueda hacer uso en cualquier otro entorno.
El resto, son historias de cuando se viajaba en carreta.
No es lo mismo saber como hay que hacer las cosas, que saber como hay que explicarlas...
Hay alguna diferencia.. algo parecido al QUE y al COMO
Yo creo que no, para mí es importante cuidar las formas y los modos, tanto en el lenguaje como en cualquier otra disciplina. De nada sirve un buen maestro que sabe el "qué" pero que no sabe explicarlo como un mal maestro que no sabe el "qué" pero tiene mucha labia :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 17:39:38 Camaleón escribió:
Entonces tendrás sólo "monólogos" contigo mismo, porque si "sólo" aplicas tus normas "sólo" te entenderás tú mismo :-)
Da la casualidad, que eso le ocurre a mucha mas gente, con lo que hablando de software, por ejemplo en vez de programari, todos nos entendemos muy bien.
Pero no es una opción práctica.
Es una cuestion de opiniones.
Sí, pero si puedo elegir entre hablar bien o hablar mal prefiero hacerlo bien. No me refiero a cuando tengo una conversación normal y cotidiana con la gente, hablo de una traducción. En una traducción existen otras necesidades y no tengo esa "flexibilidad" de la que pueda hacer uso en cualquier otro entorno.
Quen tiene la autoridad para contar lo que es hablar bien o mal....
Yo creo que no, para mí es importante cuidar las formas y los modos, tanto en el lenguaje como en cualquier otra disciplina.
Si.., pero ¿¿ quien fija las formas??? Al fin y al cabo, el que fija las normas, son la gente y su forma de expresarse, el resto..... Y si no veamos lo del guisqy
De nada sirve un buen maestro que sabe el "qué" pero que no sabe explicarlo como un mal maestro que no sabe el "qué" pero tiene mucha labia :-)
No, evidentemente, pero si no sabes el QUE, ninca podras explicar el COMO
-- Saludos Lluis
El Sun, 25 Apr 2010 17:52:04 +0200, Lluis escribió:
On Domingo, 25 de Abril de 2010 17:39:38 Camaleón escribió:
Entonces tendrás sólo "monólogos" contigo mismo, porque si "sólo" aplicas tus normas "sólo" te entenderás tú mismo :-)
Da la casualidad, que eso le ocurre a mucha mas gente, con lo que hablando de software, por ejemplo en vez de programari, todos nos entendemos muy bien.
Pero es que no se trata de saber hablar un "idioma" o no. Obviamente quien no sepa catalán te dirá que qué es eso de "programari". Se trata de que sea cual fuera el idioma que hables, que lo hagas bien. Y no me digas que ningún castellanoparlante sabe qué es un "programa".
Pero no es una opción práctica.
Es una cuestion de opiniones.
Acabas de decir que te entienden mejor si usas "software" que si dices "programari" ¿no? Pues ahí tienes un ejemplo de cómo la elección de un término u otro determina que una persona te entienda o no.
Sí, pero si puedo elegir entre hablar bien o hablar mal prefiero hacerlo bien. No me refiero a cuando tengo una conversación normal y cotidiana con la gente, hablo de una traducción. En una traducción existen otras necesidades y no tengo esa "flexibilidad" de la que pueda hacer uso en cualquier otro entorno.
Quen tiene la autoridad para contar lo que es hablar bien o mal....
Los mismos que aquéllos que la tienen para decir que dos más dos son cuatro.
Yo creo que no, para mí es importante cuidar las formas y los modos, tanto en el lenguaje como en cualquier otra disciplina.
Si.., pero ¿¿ quien fija las formas???
Las fija quien está capacitado, preparado y ha estudiado para hacerlo, claro, como en cualquier displicina.
Al fin y al cabo, el que fija las normas, son la gente y su forma de expresarse, el resto.....
Y si no veamos lo del guisqy
Bueno Lluis, en este mundo físico que nos ha tocado vivir estamos rodeados de normas y de imposiciones, más o menos coherentes (eso dependerá del gusto de cada cual, de su zona geográfica, de su educación...) pero no porque no nos gusten nos las saltamos a la torera.
De nada sirve un buen maestro que sabe el "qué" pero que no sabe explicarlo como un mal maestro que no sabe el "qué" pero tiene mucha labia :-)
No, evidentemente, pero si no sabes el QUE, ninca podras explicar el COMO
Obviamente, tiene que haber una relación equitativa entre "saber qué" y "saber expresarlo". Ambas "habilidades" suelen ir parejas. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 18:06:09 Camaleón escribió:
Quen tiene la autoridad para contar lo que es hablar bien o mal....
Los mismos que aquéllos que la tienen para decir que dos más dos son cuatro.
Pues no,. resulta que no son los mismos. Mientras la matematica como otra muchas ciencias son mas o menos demostrables por se, el lenguaje, no tiene ningun otro tipo de demostración que ser "como lo habla la gente que lo usa".
Yo creo que no, para mí es importante cuidar las formas y los modos, tanto en el lenguaje como en cualquier otra disciplina.
Si.., pero ¿¿ quien fija las formas???
Las fija quien está capacitado, preparado y ha estudiado para hacerlo, claro, como en cualquier displicina.
Y como se llama a esos??? Quizas los academicos?? Los de aqui, el estado español. o incluimos los del otro lado del charco, que tambien hablan castellano. mal llamado español, por alli? Bueno, quizas falta leer un poco mas a Cela..
Al fin y al cabo, el que fija las normas, son la gente y su forma de expresarse, el resto.....
Y si no veamos lo del guisqy
Bueno Lluis, en este mundo físico que nos ha tocado vivir estamos rodeados de normas y de imposiciones, más o menos coherentes (eso dependerá del gusto de cada cual, de su zona geográfica, de su educación...) pero no porque no nos gusten nos las saltamos a la torera.
Como deberia ser evidente, no es lo mismo la fisica ni las matematicas, mas o menos demostrables que una ortografia, solo basada en hechos mas o menos historicos.
De nada sirve un buen maestro que sabe el "qué" pero que no sabe explicarlo como un mal maestro que no sabe el "qué" pero tiene mucha labia :-)
No, evidentemente, pero si no sabes el QUE, ninca podras explicar el COMO
Obviamente, tiene que haber una relación equitativa entre "saber qué" y "saber expresarlo". Ambas "habilidades" suelen ir parejas.
Saludos,
Pues no, esa relación no existe muchas veces. Yo tuve de profesor de TV al tio que se consideraba sabia mas de eso de España en ese momento, excelente tecnico, mal profesor. En su intento de que un zoquete como yo le entendiera cambiaba la forma de explicar las cosas xcada vez que le preguntabas, el suponia que era para que lo entendieras mejor. Diez años depues consegui entender como "cjgkhgg" funcionaba una tele. -- Saludos Lluis
El Sun, 25 Apr 2010 21:06:16 +0200, Lluis escribió:
On Domingo, 25 de Abril de 2010 18:06:09 Camaleón escribió:
Quen tiene la autoridad para contar lo que es hablar bien o mal....
Los mismos que aquéllos que la tienen para decir que dos más dos son cuatro.
Pues no,. resulta que no son los mismos.
Mientras la matematica como otra muchas ciencias son mas o menos demostrables por se,
¿En qué universo? En un sistema cuántico las leyes de la física cambian que es una barbaridad y cuando usas números infinitos, también >:-)
el lenguaje, no tiene ningun otro tipo de demostración que ser "como lo habla la gente que lo usa".
No, eso es un error muy común de la gente que lo vemos desde fuera. Hay que estudiar filología, literatura, etimología... para poder hablar, no ya bien, sino con propiedad. Las reglas de la ortografía y la gramática no han salido de la nada ni las hemos inventado nosotros en el S. XXI, todo tiene un origen y un por qué, y no iba a ser menos el idioma.
Si.., pero ¿¿ quien fija las formas???
Las fija quien está capacitado, preparado y ha estudiado para hacerlo, claro, como en cualquier displicina.
Y como se llama a esos??? Quizas los academicos?? Los de aqui, el estado español. o incluimos los del otro lado del charco, que tambien hablan castellano. mal llamado español, por alli?
Que yo sepa, todos tienen cabida, sin importar nacionalidades sino intereses comunes, es decir, la lengua.
Bueno, quizas falta leer un poco mas a Cela..
Creo que sólo he leído de él La Colmena y por obligación, en mis tiempos mozos.
Bueno Lluis, en este mundo físico que nos ha tocado vivir estamos rodeados de normas y de imposiciones, más o menos coherentes (eso dependerá del gusto de cada cual, de su zona geográfica, de su educación...) pero no porque no nos gusten nos las saltamos a la torera.
Como deberia ser evidente, no es lo mismo la fisica ni las matematicas, mas o menos demostrables que una ortografia, solo basada en hechos mas o menos historicos.
¿"Hechos históricos"? :-? Costumbres o evolución, en todo caso... Para mí tiene la misma validez. No se trata de que algo sea "universalmente correcto y veraz" sino de desarrollar un sistema de comunicación "efectivo". De hecho, en la universalidad de las matemáticas tiene mucho que ver que se hayan definido "arbitrariamente" el uso de unos símbolos para designar elementos u operaciones. Si empezamos a pensar en por qué se usa una simbología en lugar de otra perdemos el norte de lo que realmente importa. Lo mismo pasa con el lenguaje: las normas sirven para no desviar la atención, para hacer un texto legible y compresible, para separar lo superfluo de lo importante. La RAE no es ningún "dogma", por eso cambia y modifica muchas de sus reglas, añade vocablos y elimina otros. Va lenta pero no es completamente estática.
No, evidentemente, pero si no sabes el QUE, ninca podras explicar el COMO
Obviamente, tiene que haber una relación equitativa entre "saber qué" y "saber expresarlo". Ambas "habilidades" suelen ir parejas.
Pues no, esa relación no existe muchas veces. Yo tuve de profesor de TV al tio que se consideraba sabia mas de eso de España en ese momento, excelente tecnico, mal profesor. En su intento de que un zoquete como yo le entendiera cambiaba la forma de explicar las cosas xcada vez que le preguntabas, el suponia que era para que lo entendieras mejor. Diez años depues consegui entender como "cjgkhgg" funcionaba una tele.
Bueno, a lo mejor era un "crack" en su campo pero no en otros. Eso nos puede pasar a todos. O quizá el problema estaba en el interlocutor -en el caso de que el resto de alumnos sí le entendieran- >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Domingo, 25 de Abril de 2010 21:47:44 Camaleón escribió:
Y como se llama a esos??? Quizas los academicos?? Los de aqui, el estado español. o incluimos los del otro lado del charco, que tambien hablan castellano. mal llamado español, por alli?
Que yo sepa, todos tienen cabida, sin importar nacionalidades sino intereses comunes, es decir, la lengua.
Bueno, quizas falta leer un poco mas a Cela..
Tsee, bastante fomes tus argumentos. :-) -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-04-25 a las 21:06 +0200, Lluis escribió:
On Domingo, 25 de Abril de 2010 18:06:09 Camaleón escribió:
Las fija quien está capacitado, preparado y ha estudiado para hacerlo, claro, como en cualquier displicina.
Y como se llama a esos??? Quizas los academicos?? Los de aqui, el estado español. o incluimos los del otro lado del charco, que tambien hablan castellano. mal llamado español, por alli?
La RAE va de la mano con el resto de academias de la lengua española. ...
Diez años depues consegui entender como "cjgkhgg" funcionaba una tele.
Y ahora no te servirá de nada porque ha cambiado >:-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkvU0ogACgkQtTMYHG2NR9VBiACfdzfjO0BfB7Ecc3v+YnsXaUKI 8QAAnjpIJZZMBkpGFrm/WtZzkDh4QtkQ =/BOT -----END PGP SIGNATURE-----
Hola :) On Monday 26 April 2010 01:38 Carlos E. R. wrote [...]
Diez años depues consegui entender como "cjgkhgg" funcionaba una tele.
Y ahora no te servirá de nada porque ha cambiado >:-P
Y lo que se avecina ... =:0 Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-26 10:34, Rafa Grimán wrote:
Hola :)
On Monday 26 April 2010 01:38 Carlos E. R. wrote
[...]
Diez años depues consegui entender como "cjgkhgg" funcionaba una tele.
Y ahora no te servirá de nada porque ha cambiado >:-P
Y lo que se avecina ... =:0
¿El que? :-O - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVaEwACgkQU92UU+smfQUD7gCfYpegCKnE7iAwPr5jpfvxMk1C 278AnjbhGBE2OYiDlRNEP+g/HZkhxobI =Pi77 -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Monday 26 April 2010 12:17 Carlos E. R. wrote
On 2010-04-26 10:34, Rafa Grimán wrote:
Hola :)
On Monday 26 April 2010 01:38 Carlos E. R. wrote
[...]
Diez años depues consegui entender como "cjgkhgg" funcionaba una tele.
Y ahora no te servirá de nada porque ha cambiado >:-P
Y lo que se avecina ... =:0
¿El que? :-O
Ahora mismo están con el HD y alguno con estereoscopía (lo que la gente llama 3D). Después de eso viene HD + estereoscopía. Actualmente la estereoscopía no es FullHD, la señal se parte en dos y cada ojo recibe un "trozo". Para los más veteranos, ¿os acordáis del entrelazado en los CRT? Pues algo así. En un futuro, la estereoscopía sí será FullHD: cada ojo recibirá un frame FullHD. También están con el rollo de TVs interactivas a modo de TV+Redes Sociales. Es decir, que puedas estar viendo tu serie preferida y ves a tus amiguitos en una franja a la derecha/izquierda/arriba/abajo (bueno, ves sus avatares o como se llamen esos monigotes ... los de la red social, los de la tele se llaman actores ;) Imagínate que te gusta la camisa que lleva tu actor preferido, pues puedes comprar esa camisa y tus amigotes de la red social "ven" que te la has comprado ... tus amigotes pueden ahora marujear (chisme, metiche) sobre tu compra y tu sobre la suya. Como si no perdiéramos bastante el tiempo ya ... A ver si consigo montar la granja de caracoles ;) ¿Me pregunto si te podrás comprar un Taun-Taun o Baroness (G. I. Joe) o Starscream? Me refiero a los de verdad, nada de peluches y figuritas ;) Una espada láser no porque con lo torpe que soy y lo que me tiembla el pulso, seguro que me corto 0:) La otra es IPTV (TV por Internet) ... pero eso ya hace falta colaboración por parte de Timofónica, Mono, Potaphon y demás. Con los anchos de banda que tenemos en España ... dudo que podamos emitir tal y como se emite por la TV "convencional" todos los canales que hay ... aunque para lo que hay que ver. En países civilizados tienes servicios como Hulu, Zatoo y otros que emiten y parece que va bien. ¿Alguien lo ha probado? Físicamente, están con las pantallas OLED: auténticas maravillas :)" Buscad en Internet por OLED. NOTA: si buscáis en YouTube ... tened cerca alguien que os pueda reanimar. Si os acabáis de comprar una TV plana ... NO busquéis: os pondrá de muy mal humor ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.2 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-26 13:00, Rafa Grimán wrote:
Hola :)
On Monday 26 April 2010 12:17 Carlos E. R. wrote
On 2010-04-26 10:34, Rafa Grimán wrote:
Hola :)
On Monday 26 April 2010 01:38 Carlos E. R. wrote
[...]
Diez años depues consegui entender como "cjgkhgg" funcionaba una tele.
Y ahora no te servirá de nada porque ha cambiado >:-P
Y lo que se avecina ... =:0
¿El que? :-O
Ahora mismo están con el HD y alguno con estereoscopía (lo que la gente llama 3D). Después de eso viene HD + estereoscopía. Actualmente la estereoscopía no es FullHD, la señal se parte en dos y cada ojo recibe un "trozo". Para los más veteranos, ¿os acordáis del entrelazado en los CRT? Pues algo así. En un futuro, la estereoscopía sí será FullHD: cada ojo recibirá un frame FullHD.
Ah, si, con unas gafas con "cortinilla" que abre y cierra cada ojo alternadamente. Lo oí. Chapucero. :-p
También están con el rollo de TVs interactivas a modo de TV+Redes Sociales.
¿La famosa TDT interactiva que nadie tiene?
Es decir, que puedas estar viendo tu serie preferida y ves a tus amiguitos en una franja a la derecha/izquierda/arriba/abajo (bueno, ves sus avatares o como se llamen esos monigotes ... los de la red social, los de la tele se llaman actores ;) Imagínate que te gusta la camisa que lleva tu actor preferido, pues puedes comprar esa camisa y tus amigotes de la red social "ven" que te la has comprado ... tus amigotes pueden ahora marujear (chisme, metiche) sobre tu compra y tu sobre la suya. Como si no perdiéramos bastante el tiempo ya ... A ver si consigo montar la granja de caracoles ;)
Huy, ¡que chuli! ¡Como molaaaa! :-p
¿Me pregunto si te podrás comprar un Taun-Taun o Baroness (G. I. Joe) o Starscream? Me refiero a los de verdad, nada de peluches y figuritas ;) Una espada láser no porque con lo torpe que soy y lo que me tiembla el pulso, seguro que me corto 0:)
Pues no creo...
La otra es IPTV (TV por Internet) ... pero eso ya hace falta colaboración por parte de Timofónica, Mono, Potaphon y demás. Con los anchos de banda que tenemos en España ... dudo que podamos emitir tal y como se emite por la TV "convencional" todos los canales que hay ... aunque para lo que hay que ver.
Supongo que podríamos recibir un canal por casa, es decir, por conexión. ¿Pero cada casa con un canal distinto, y cada una viendo por una posición distinta, sin horarios fijos? Buff... miedo me da.
En países civilizados tienes servicios como Hulu, Zatoo y otros que emiten y parece que va bien. ¿Alguien lo ha probado?
Ja. Se me ocurrió pinchar en un enlace que me pareción interesante en gmail. Era a un video de hulu. Empieza a cargar... hasta que me dice que sólo usanianos. Claro, que gmail, que tiene auncios contextuales, me puso uno de esos anonimizadores P-) No lo probé.
Físicamente, están con las pantallas OLED: auténticas maravillas :)" Buscad en Internet por OLED. NOTA: si buscáis en YouTube ... tened cerca alguien que os pueda reanimar. Si os acabáis de comprar una TV plana ... NO busquéis: os pondrá de muy mal humor ;)
Las conozco de referencia desde hace tiempo, de publicaciones técnicas. Bajo consumo, enrollables... En la wikipedia hay un buen artículo. Incluyendo las pegas... así se os rebajará el mal humor ;-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVitEACgkQU92UU+smfQWpkACfc5XlpeL3Za484B7bYpvjeJMo zVgAn3jg6KEU9wW9XP8T696ZchDmxCcU =G2Mf -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 26 Apr 2010 14:45:05 +0200, Carlos E. R. escribió:
On 2010-04-26 13:00, Rafa Grimán wrote:
Y lo que se avecina ... =:0
¿El que? :-O
Ahora mismo están con el HD y alguno con estereoscopía (lo que la gente llama 3D). Después de eso viene HD + estereoscopía. Actualmente la estereoscopía no es FullHD, la señal se parte en dos y cada ojo recibe un "trozo". Para los más veteranos, ¿os acordáis del entrelazado en los CRT? Pues algo así. En un futuro, la estereoscopía sí será FullHD: cada ojo recibirá un frame FullHD.
Ah, si, con unas gafas con "cortinilla" que abre y cierra cada ojo alternadamente. Lo oí. Chapucero. :-p
Je, para los que están "a destajo" con el FullHD: http://xkcd.com/732/
También están con el rollo de TVs interactivas a modo de TV+Redes Sociales.
¿La famosa TDT interactiva que nadie tiene?
No, es una nueva forma de "enter[ton]tainment". La está poniendo de moda Sony y también Panasonic creo que ha sacado algo. No es más que TV "con" (que no "a través de") Internet. Como se ve que nadie ve la "tele" y tienen que vender "teles", pues se han sacado esta opción de la manga. Ahora la tele tendrá "bugs" :-) (...) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-04-26 18:07, Camaleón wrote:
El Mon, 26 Apr 2010 14:45:05 +0200, Carlos E. R. escribió:
Ah, si, con unas gafas con "cortinilla" que abre y cierra cada ojo alternadamente. Lo oí. Chapucero. :-p
Je, para los que están "a destajo" con el FullHD:
Ah, pero si ya lo dije yo, cuando estaba por comprarme un monitor. Y no soy yo solo: http://slashdot.org/submission/1221626/HDTV-Has-Ruined-the-LCD-Display-Marke... http://10rem.net/blog/2010/04/22/rant-hdtv-has-ruined-the-lcd-display-market... Rant: HDTV Has Ruined the LCD Display Market: Or, I want my pixels and DPI now! Rants Technology Ok, that's it. I've had it. I want my pixels, damn-it! For a while, screen resolution has been going up on our desktop displays. The trend was good, as I've always wanted the largest monitor with the highest DPI that I could afford. I mean, I used to have one of the first hulking 17" CRTs on my desk. I later upgraded to a 21" inch job that was so huge, that if you didn't stick it in a corner, it took up the whole desk. It was flat-panel, though and full of pixels. It cost me around $1100 at the time. Ah, y como el tio es de Microsoft, va uno y le dice que el problema no son los monitores, sino que usa un sistema operativo inútil, que se pase al linux. ¿¡Sera...!?
También están con el rollo de TVs interactivas a modo de TV+Redes Sociales.
¿La famosa TDT interactiva que nadie tiene?
No, es una nueva forma de "enter[ton]tainment". La está poniendo de moda Sony y también Panasonic creo que ha sacado algo.
Ah.
No es más que TV "con" (que no "a través de") Internet. Como se ve que nadie ve la "tele" y tienen que vender "teles", pues se han sacado esta opción de la manga.
Pos ni idea.
Ahora la tele tendrá "bugs" :-)
¡Pero si ya los tienen! - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkvV0+UACgkQja8UbcUWM1yWAgD/VUwipnVS+3gbaZQPC78a4fId oSPETEPFU0Ox5Cznz6sA+wXV1kzRTqJmhP/eL9YtYlh6TD2D0U5m/lPiKlGPLbdu =gL4h -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 26 Apr 2010 19:56:53 +0200, Carlos E. R. escribió:
On 2010-04-26 18:07, Camaleón wrote:
(...)
Ahora la tele tendrá "bugs" :-)
¡Pero si ya los tienen!
Sí, pero ahora con acceso al "sat-zilla¹" directamente desde el propio televisor ;-P ¹ Sat-zilla: dícese del Servicio de Asistencia Técnica integrado con un sistema de gestión de bugs. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-25 16:54, Lluis wrote:
On Domingo, 25 de Abril de 2010 13:38:02 Camaleón escribió:
El idioma no lo crean ni lo desarrollan ni lo definen los fabricantes o los sectores de las industrias sino los académicos y catedráticos de la lengua, es decir, los que se suponen que saben de eso :-)
Sorry, Error El idioma no lo definen loa academicos, ni los catedraticos, ni otros santos gurus.
El idioma se define popr lo que habla la gente, tu y yo.......
El resto es academicismo y falacia.
El idioma lo define la gente al usarlo, y eso por cierto, es lo que dice la RAE. La RAE no define, simplemente toma nota. La RAE, al poner en su diccionario los significados de archivo y fichero se limitan a constatar el hecho. No se les puede tachar de academicistas por eso. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvUavQACgkQU92UU+smfQVLhQCeK2urqm+LRdawhyUmBvbUDM6W BocAmwbC4VN75VZIjh2nl8tXY1eN/+d8 =R2rn -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sun, 25 Apr 2010 18:16:52 +0200, Carlos E. R. escribió:
On 2010-04-25 16:54, Lluis wrote:
El idioma se define popr lo que habla la gente, tu y yo.......
El resto es academicismo y falacia.
El idioma lo define la gente al usarlo, y eso por cierto, es lo que dice la RAE. La RAE no define, simplemente toma nota.
No siempre. Dime a ver quién usa "cederrón" :-) Bueno, pues está ahí, admitido por la RAE. Perfecto, yo seguiré usando "disco compacto" o "CD", porque también son válidos. Será que no hay formas de hablar bien y acorde a nuestros gustos...
La RAE, al poner en su diccionario los significados de archivo y fichero se limitan a constatar el hecho. No se les puede tachar de academicistas por eso.
Para "desgracia" de algunos, el español es muy rico en su vocabulario, en matices y significados, en juegos de palabras, en "calambures"... la cantidad de recursos lingüísticos que existen y que se usan en literatura son enormes. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :)
On Sunday 25 April 2010 01:27 Camaleón wrote
El Sat, 24 Apr 2010 22:59:17 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 21:39 Carlos E. R. wrote
Content-ID:
El 2010-04-23 a las 13:32 +0200, Rafa Grimán escribió:
...
Por cierto, ya sé que tu no haces distinción entre archivo y fichero, pero en el mundo del almacenamiento sí se hac distinción porque NO son lo mismo.
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente.
No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta.
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son.
El lenguaje nada tiene que ver con el mundo del almacenamiento :-)
¿Y cómo nos comunicamos? ;)
Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión.
No Rafa, no es tan sencillo. No puedes ignorar las normas de un idioma sólo "porque no te conviene" o "porque lía a tus clientes/proveedores".
Perdona, pero los términos definieron esos proveedores/fabricantes mucho antes de que los usuarios lo hicieran ;)
Para traducir openSUSE tuvimos que llegar a un consenso por razones lógicas y razonadas (hay palabras que no se usan en todos los países donde se habla español). Es decir, "forzamos" el uso de una palabra en concreto porque tenemos que usar un español neutro. Pero al hacerlo no nos saltamos ninguna normativa de la RAE.
No he dicho que os saltéis la normativa de la RAE.
Lo que es "artificial" es cambiar/forzar el uso de una palabra en español sólo porque el término en inglés usa dos vocablos distintos pero en español el mismo término admite varias acepciones que sirven además
O Domingo 25 Abril 2010 13:08:34 Rafa Grimán escribiu: para
ambas. Al hacer eso estás "adulterando" el idioma sin ninguna base lingüística ni de ninguna otra índole.
No señor, no es en inglés, en castellano también existía esa distinción.
Vamos, ¿habláis de la distinción de archivo y fichero? http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=archivo http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=fichero Salud!! -- karl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-24 22:59, Rafa Grimán wrote:
Hola :)
On Friday 23 April 2010 21:39 Carlos E. R. wrote
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente.
No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta.
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son.
Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión.
No es eso. El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error). No me gusta, no estoy de acuerdo, pero es un hecho. Desgraciado, pero es un hecho. Como también es un hecho que file no es lo mismo que archive. El unico remedio que nos queda es asignar una palabra nueva a archive, y decidimos que fuera "archivador". Si crees que deberíamos traducir archive por archivo, y file por fichero (y sólo conozco dos personas que piensan así), pues oye, haz un openFATE, busca gente que piense así, y que lo voten. Ya sabes, es el sistema oficial de openSUSE para votar cambios >>>>:-) (<-sonrisa muy malvada) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvTj/oACgkQU92UU+smfQWUaACdGQHvQ1J+qosxf7bue0qqru9H MJkAniKFGkcqucUkdrMiWkqvKB8oiRel =9TVf -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Sunday 25 April 2010 02:42 Carlos E. R. wrote
On 2010-04-24 22:59, Rafa Grimán wrote:
Hola :)
On Friday 23 April 2010 21:39 Carlos E. R. wrote
Decidimos que archive sería archivador, y file seguiría siendo fichero o archivo, indistintamente.
No es que me guste, preferiría distinguir archivo de fichero, pero en el mundo de los pequeños significa lo mismo. Así que en openSUSE decidimos traducir por otra palabra totalmente distinta.
Ya leí el thread. Pero es una decisión propia que no tiene que ver con el mundo del almacenamiento. De la misma manera, puede venir alguien y decir que core y socket son lo mismo ... cuando no lo son.
Si decidimos por nuestra propia cuenta usar determinados términos ... podemos llevar a confusión.
No es eso.
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error). No me gusta, no estoy de acuerdo, pero es un hecho. Desgraciado, pero es un hecho.
Como también es un hecho que file no es lo mismo que archive.
¿No sería mejor corregir ese error?
El unico remedio que nos queda es asignar una palabra nueva a archive, y decidimos que fuera "archivador".
Si crees que deberíamos traducir archive por archivo, y file por fichero (y sólo conozco dos personas que piensan así), pues oye, haz un openFATE, busca gente que piense así, y que lo voten.
No sería en openFATE donde hay que reportarlo, es en la RAE ya que según decís, la RAE acepta ambos como sinónimos.
Ya sabes, es el sistema oficial de openSUSE para votar cambios >>>>:-) (<-sonrisa muy malvada)
Ya ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sun, 25 Apr 2010 13:11:44 +0200, Rafa Grimán escribió:
On Sunday 25 April 2010 02:42 Carlos E. R. wrote
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error). No me gusta, no estoy de acuerdo, pero es un hecho. Desgraciado, pero es un hecho.
Como también es un hecho que file no es lo mismo que archive.
¿No sería mejor corregir ese error?
Es que no es ningún "error" :-)
El unico remedio que nos queda es asignar una palabra nueva a archive, y decidimos que fuera "archivador".
Si crees que deberíamos traducir archive por archivo, y file por fichero (y sólo conozco dos personas que piensan así), pues oye, haz un openFATE, busca gente que piense así, y que lo voten.
No sería en openFATE donde hay que reportarlo, es en la RAE ya que según decís, la RAE acepta ambos como sinónimos.
En ningún sitio, porque tenemos que usar el español neutro y "fichero" no se usa en otros lugares, ya te lo he dicho. Pásate por los glosarios de cualquier desarrollo en el que participe gente de todos los países de habla española (no sólo España) y lo verás: http://i18n.kde.org/teams/es/glosario.php Y estos han optado por una solución "peor" (desde mi punto de vista) porque "archive" no tiene por qué estar "comprimido", eso ya lo comentamos en su día también. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-25 13:11, Rafa Grimán wrote:
Hola :)
On Sunday 25 April 2010 02:42 Carlos E. R. wrote
No es eso.
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error). No me gusta, no estoy de acuerdo, pero es un hecho. Desgraciado, pero es un hecho.
Como también es un hecho que file no es lo mismo que archive.
¿No sería mejor corregir ese error?
¿Como? Si me vas a decir que traduzcamos archive por archivo y fichero por file, te contestaré que sólo dos personas opinan así (tu y yo), el resto está en contra, que yo recuerde. A no ser que haya un voto masivo para apoyar ese sistema, no lo haremos. Así de simple :-) Por lo menos en openSUSE.
El unico remedio que nos queda es asignar una palabra nueva a archive, y decidimos que fuera "archivador".
Si crees que deberíamos traducir archive por archivo, y file por fichero (y sólo conozco dos personas que piensan así), pues oye, haz un openFATE, busca gente que piense así, y que lo voten.
No sería en openFATE donde hay que reportarlo, es en la RAE ya que según decís, la RAE acepta ambos como sinónimos.
La RAE no cambia cosas, se limita a constatar el hecho. Registran las palabras, no imponen cambios. La cosa va al revés: el habla cambia y entonces ellos lo ponen en el diccionario. Y no aceptan presiones, por cierto. Ya mandaron a paseo a Franco en su dia, y ahora mandan a paseo a las ministras de turno con sus proposiciones de nueva política correcta. O a los del bloque nacionalista gallego, que querían que se quitara una acepción de "gallego" del diccionario: “En la quinta y sexta acepciones de la palabra gallego, una con marca de Costa Rica y otra de El Salvador, se precisa que ese gentilicio es utilizado allí con el significado de tonto (falto de entendimiento o de razón) y de tartamudo.” Unos ejemplitos de Arturo Perez Reverte Sobre gallegos y diccionarios http://xlsemanal.finanzas.com/web/firma.php?id_edicion=5127&id_firma=2590 Matrimonios de género y otras cosas http://xlsemanal.finanzas.com/web/firma.php?id_edicion=5127&id_firma=3431 MIEMBRAS Y CARNE DE MIEMBRILLO http://xlsemanal.finanzas.com/web/firma.php?id_firma=6530&id_edicion=3227 La osadía de la ignorancia http://xlsemanal.finanzas.com/web/firma.php?id_firma=2230&id_edicion=847 - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvUQQcACgkQU92UU+smfQUtfgCfVc/eILFSu4xvOYywKvzsLYkF neUAoJSdaUvBTbgAuQ9733VeXN1kQJBE =iljd -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sun, 25 Apr 2010 15:17:59 +0200, Carlos E. R. escribió:
Si me vas a decir que traduzcamos archive por archivo y fichero por file, te contestaré que sólo dos personas opinan así (tu y yo), el resto está en contra, que yo recuerde. A no ser que haya un voto masivo para apoyar ese sistema, no lo haremos. Así de simple :-)
Por lo menos en openSUSE.
¿Qué "cómo"? Muy fácil. Le decís a Karl que queréis traducir openSUSE usando español de España y os creará una rama "es_ES", os asignáis como traductores y podéis empezar a usar "Fichero" tanto como queráis >:-)
La RAE no cambia cosas, se limita a constatar el hecho. Registran las palabras, no imponen cambios.
La cosa va al revés: el habla cambia y entonces ellos lo ponen en el diccionario.
Y no aceptan presiones, por cierto.
Afortunadamente...
Ya mandaron a paseo a Franco en su dia, y ahora mandan a paseo a las ministras de turno con sus proposiciones de nueva política correcta. O a los del bloque nacionalista gallego, que querían que se quitara una acepción de "gallego" del diccionario: “En la quinta y sexta acepciones de la palabra gallego, una con marca de Costa Rica y otra de El Salvador, se precisa que ese gentilicio es utilizado allí con el significado de tonto (falto de entendimiento o de razón) y de tartamudo.”
Unos ejemplitos de Arturo Perez Reverte
(...) No es que sea de mis preferidos, pero mira, en una cosa del doy la razón al Sr. Reverte y es que "España es un país gozosamente inculto¹". Y yo añadiría, además, que -desgraciadamente- nos sentimos "gozosamente" orgullosos de serlo. ¹ http://www.elcultural.es/version_papel/LETRAS/26696/Arturo_Perez_Reverte Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-25 15:39, Camaleón wrote:
El Sun, 25 Apr 2010 15:17:59 +0200, Carlos E. R. escribió:
Si me vas a decir que traduzcamos archive por archivo y fichero por file, te contestaré que sólo dos personas opinan así (tu y yo), el resto está en contra, que yo recuerde. A no ser que haya un voto masivo para apoyar ese sistema, no lo haremos. Así de simple :-)
Por lo menos en openSUSE.
¿Qué "cómo"? Muy fácil.
Le decís a Karl que queréis traducir openSUSE usando español de España y os creará una rama "es_ES", os asignáis como traductores y podéis empezar a usar "Fichero" tanto como queráis >:-)
No hay quorum para eso. Y aunque lo hubiera para cambiar, no lo habría luego para mantenerlo. Además de que no creo que deban haber tantas versiones de la traducción, somos pocos.
Unos ejemplitos de Arturo Perez Reverte
(...)
No es que sea de mis preferidos, pero mira, en una cosa del doy la razón al Sr. Reverte y es que "España es un país gozosamente inculto¹". Y yo añadiría, además, que -desgraciadamente- nos sentimos "gozosamente" orgullosos de serlo.
¹ http://www.elcultural.es/version_papel/LETRAS/26696/Arturo_Perez_Reverte
Lo leeré luego, es largo. El libro es mi libro de cabecera en este momento, por cierto. [...] Ah, ya decía yo que me sonaba el artículo, es que lo leí en papel cuando salió. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvUTSYACgkQU92UU+smfQV6ZgCfeOu+3nu91hBVxlbsRMmxKM8R eNoAnj6WCuq0XeJyIXCF6c1Ne8ccHUfR =Yrhz -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
O Domingo 25 Abril 2010 13:11:44 Rafa Grimán escribiu:
(..:)
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error).(...) Creo que ése es el punto: Microsoft cometión un error -o no, puede que sea influencia latina o lo que sea...
En la edición electrónica de la 22ª edición del diccionario de la RAE sí hay diferencia; pero en "fichero" el artículo está enmendado y como avance de la 23ª edición figura como sinónimo de "archivo". Usar este "avance" sobre la 23ª edición de un diccionario para sacar conclusiones sobre el correcto uso de un término, creo que es muuy exagerado. Nótese que las definiciones de la 22ª edición incluyen los términos específicos informáticos. Salud!! -- karl
O Domingo 25 Abril 2010 13:11:44 Rafa Grimán escribiu:
(..:)
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error).(...) Creo que ése es el punto: Microsoft cometión un error -o no, puede que sea influencia latina o lo que sea...
En la edición electrónica de la 22ª edición del diccionario de la RAE sí hay diferencia; pero en "fichero" el artículo está enmendado y como avance de la 23ª edición figura como sinónimo de "archivo". Usar este "avance" sobre la 23ª edición de un diccionario para sacar conclusiones sobre el correcto uso de un término, creo que es muuy exagerado. Nótese que las definiciones de la 22ª edición incluyen los términos específicos informáticos. Salud!! -- karl
O Domingo 25 Abril 2010 13:11:44 Rafa Grimán escribiu:
(..:)
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error).(...) Creo que ése es el punto: Microsoft cometión un error -o no, puede que sea influencia latina o lo que sea...
En la edición electrónica de la 22ª edición del diccionario de la RAE sí hay diferencia; pero en "fichero" el artículo está enmendado y como avance de la 23ª edición figura como sinónimo de "archivo". Usar este "avance" sobre la 23ª edición de un diccionario para sacar conclusiones sobre el correcto uso de un término, creo que es muuy exagerado. Nótese que las definiciones de la 22ª edición incluyen los términos específicos informáticos. Salud!! -- karl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-26 22:11, Karl García Gestido wrote: Tus correos me llegan por triplicado, con distinto minutaje de salida.
O Domingo 25 Abril 2010 13:11:44 Rafa Grimán escribiu:
(..:)
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error).(...)
Eso no lo dijo Rafa, lo dije yo.
Creo que ése es el punto: Microsoft cometión un error -o no, puede que sea influencia latina o lo que sea...
Puede.
En la edición electrónica de la 22ª edición del diccionario de la RAE sí hay diferencia; pero en "fichero" el artículo está enmendado y como avance de la 23ª edición figura como sinónimo de "archivo".
Usar este "avance" sobre la 23ª edición de un diccionario para sacar conclusiones sobre el correcto uso de un término, creo que es muuy exagerado.
No, no hemos usado la edición enmendada. Hemos usado esa, otras, y otras fuentes. Es una discusión antigua, llevamos años con esto. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvV9tkACgkQU92UU+smfQUS1ACghi7DO6LzR/oyNGxW9mvoOqS0 tiYAnj6qT0TkSUExLi4oTR758xZj7EyG =3/WD -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
O Luns 26 Abril 2010 22:26:02 Carlos E. R. escribiu:
On 2010-04-26 22:11, Karl García Gestido wrote:
Tus correos me llegan por triplicado, con distinto minutaje de salida. Culpable... patina mi cuenta de correo habitual, y la he cambiado, aunque mantengo la suscripción en la misma. Espero no dé más problemas.
O Domingo 25 Abril 2010 13:11:44 Rafa Grimán escribiu:
(..:)
El hecho es que, en español, archivo y fichero significan lo mismo. Figura en el diccionario de la RAE. Así es como lo traduce Microsoft (probablemente sean ellos los culpables de este error).(...)
Eso no lo dijo Rafa, lo dije yo. sip
Creo que ése es el punto: Microsoft cometión un error -o no, puede que sea influencia latina o lo que sea...
Puede.
En la edición electrónica de la 22ª edición del diccionario de la RAE sí hay diferencia; pero en "fichero" el artículo está enmendado y como avance de la 23ª edición figura como sinónimo de "archivo".
Usar este "avance" sobre la 23ª edición de un diccionario para sacar conclusiones sobre el correcto uso de un término, creo que es muuy exagerado.
No, no hemos usado la edición enmendada. Hemos usado esa, otras, y otras fuentes. Es una discusión antigua, llevamos años con esto. Lo comento porque tener una autoridad central es muy útil, pero no debería ser algo sagrado. De hecho, gran parte de la terminología que usamos no está aprobada.
En la 22ª edición fichero no es lo mismo que archivo. No me queda claro si eso es como debe de ser o no, personalmente encuentro confusas las definiciones de cada edición :S ... pero, con ánimo de maldad >:-) , en este caso no podemos aludir a la RAE para indicar que ambos términos son lo mismo. Salud!! -- karl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-04-26 23:24, Karl García Gestido wrote:
O Luns 26 Abril 2010 22:26:02 Carlos E. R. escribiu:
No, no hemos usado la edición enmendada. Hemos usado esa, otras, y otras fuentes. Es una discusión antigua, llevamos años con esto.
Lo comento porque tener una autoridad central es muy útil, pero no debería ser algo sagrado. De hecho, gran parte de la terminología que usamos no está aprobada.
En la 22ª edición fichero no es lo mismo que archivo. No me queda claro si eso es como debe de ser o no, personalmente encuentro confusas las definiciones de cada edición :S ... pero, con ánimo de maldad >:-) , en este caso no podemos aludir a la RAE para indicar que ambos términos son lo mismo.
fichero. 1. m. Caja o mueble con cajonería donde se pueden guardar ordenadamente las fichas. 2. m. Inform. Conjunto organizado de informaciones almacenadas en un soporte común. Artículo enmendado (23ed) 1. m. Caja o mueble con cajonería donde se pueden guardar ordenadamente las fichas. 2. m. Inform. archivo (‖ conjunto de información). archivo. 5. m. Inform. Espacio que se reserva en el dispositivo de memoria de un computador para almacenar porciones de información que tienen la misma estructura y que pueden manejarse mediante una instrucción única. 5. m. Inform. Conjunto de información almacenada en la memoria de una computadora que puede manejarse con una instrucción única. La definición actual de archivo es falsa o absurda. La enmendada tampoco tiene sentido. ¿Memoria? Los archivos no están en memoria, están en dispositivos de almacenamiento permanente, para darles el nombre correcto a los discos y similares. La de fichero actual tiene sentido, pero la enmendada es extraña. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkvWCCwACgkQja8UbcUWM1w91AD+P9H3lt+TNl/th/hMHMbpjzLK f890o2mMJBA6xC7WjkgBAIZoWEvhx+PZ1v9Cj+aApJAxkQ4bFI+cBQrGqtdCejbx =6zMd -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
O Luns 26 Abril 2010 23:39:56 Carlos E. R. escribiu:
(...)
La definición actual de archivo es falsa o absurda. La enmendada tampoco tiene sentido. ¿Memoria? Los archivos no están en memoria, están en dispositivos de almacenamiento permanente, para darles el nombre correcto a los discos y similares.
La de fichero actual tiene sentido, pero la enmendada es extraña. Lo que no está mal para una discusión sobre la conveniencia de seguir los dictados de la RAE, ¿no? xD
Salud!! -- karl
On Tuesday 27 April 2010 00:55 Karl García Gestido wrote
O Luns 26 Abril 2010 23:39:56 Carlos E. R. escribiu:
(...)
La definición actual de archivo es falsa o absurda. La enmendada tampoco tiene sentido. ¿Memoria? Los archivos no están en memoria, están en dispositivos de almacenamiento permanente, para darles el nombre correcto a los discos y similares.
La de fichero actual tiene sentido, pero la enmendada es extraña.
Lo que no está mal para una discusión sobre la conveniencia de seguir los dictados de la RAE, ¿no? xD
100% de acuerdo ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.2 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tue, 27 Apr 2010 00:55:51 +0200, Karl García Gestido escribió:
O Luns 26 Abril 2010 23:39:56 Carlos E. R. escribiu:
(...)
La definición actual de archivo es falsa o absurda. La enmendada tampoco tiene sentido. ¿Memoria? Los archivos no están en memoria, están en dispositivos de almacenamiento permanente, para darles el nombre correcto a los discos y similares.
La de fichero actual tiene sentido, pero la enmendada es extraña.
Lo que no está mal para una discusión sobre la conveniencia de seguir los dictados de la RAE, ¿no? xD
Que yo sepa, la RAE no es un diccionario "especializado", no se le pueden atribuir capacidades que no tiene ni competencias ajenas (aunque entiendo que contarán con la colaboración de expertos en distintas materias, el diccionario de la RAE no es una enciclopedia temática) :-) Por ejemplo, si buscas "bronquitis" te aparecerá una definición que un diccionario de medicina podría cuanto menos, matizar. Es decir, si quieres saber qué se considera un "fichero" o un "archivo" en informática, tienes que consultar no uno, sino varios, diccionarios especializados de informática. Y si quieres saber qué es una "bronquitis", tendrás que consultar un vademécum de medicina. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
O Martes 27 Abril 2010 09:34:06 Camaleón escribiu:
El Tue, 27 Apr 2010 00:55:51 +0200, Karl García Gestido escribió:
O Luns 26 Abril 2010 23:39:56 Carlos E. R. escribiu:
(...)
La definición actual de archivo es falsa o absurda. La enmendada tampoco tiene sentido. ¿Memoria? Los archivos no están en memoria, están en dispositivos de almacenamiento permanente, para darles el nombre correcto a los discos y similares.
La de fichero actual tiene sentido, pero la enmendada es extraña.
Lo que no está mal para una discusión sobre la conveniencia de seguir los dictados de la RAE, ¿no? xD
Que yo sepa, la RAE no es un diccionario "especializado", no se le pueden atribuir capacidades que no tiene ni competencias ajenas (aunque entiendo que contarán con la colaboración de expertos en distintas materias, el diccionario de la RAE no es una enciclopedia temática) :-)
Por ejemplo, si buscas "bronquitis" te aparecerá una definición que un diccionario de medicina podría cuanto menos, matizar.
Es decir, si quieres saber qué se considera un "fichero" o un "archivo" en informática, tienes que consultar no uno, sino varios, diccionarios especializados de informática. Y si quieres saber qué es una "bronquitis", tendrás que consultar un vademécum de medicina.
Saludos, Creo que el Diccionario está muy bien, pero, como cualquier cosa que dependa de gente, tiene sus fallos...
Es decir, en el último siglo el fuerte desarrollo técnico y científico -¿o ambas cosas son la misma ;) ?- hizo que floreciese un amplio vocabulario, normalmente formado a partir de los términos que usaban los diversos especialistas de este ámbito, que, vaya por Monesvol, solían cometer la herejía de usar inglés donde debieran usar Griego o Latín... el que los originales ingleses en ocasiones partiesen del latín y, en menos ocasiones, no, no hizo más que complicar la cuestión. Por ejemplo, hay muchos casos donde un tecnicismo moderno deriva del latín a través del inglés, pero esa palabra latina ya tenía correspondiente en castellano. En otras ocasiones, simplemente se crean modismos que no se ajustan a la gramática castellana. Es erróneo pensar que el ámbito informático es donde más sucede, si bien lo cierto es que en el contexto de listas de correo y foros informáticos éstos son los problemas que más nos atañen. Sin embargo, es en el márketing moderno donde más se observa este fenómeno: se toma una palabra de moda en inglés, se "castellaniza" y ya está... por muy incorrecta o innecesaria que sea tal castellanización... Ahora acaban de sacar, por fin, la nueva edición de la gramática. Creo que muchos (o todos) deberíamos al menos ojearla... seguro que nos depara muchas sorpresas xD Dicho todo esto, el diccionario está bastante bien para ayudar a comprender términos concretos. Creo que cuando un término está bien recogido, asentado en el habla, es lo mejor para usar como regla. Salud!! -- karl
Buenos días, me parece que la definición de la wikipedia es suficiente, qué opinan: Un archivo informático o fichero es un conjunto de bits almacenado en un dispositivo periférico. Un archivo es identificado por un nombre y la descripción de la carpeta o directorio que lo contiene. Los archivos informáticos se llaman así porque son los equivalentes digitales de los archivos en tarjetas, papel o microfichas del entorno de oficina tradicional. Los archivos informáticos facilitan una manera de organizar los recursos usados para almacenar permanentemente datos en un sistema informático. En la RAE dice: ARCHIVO (Del lat. archīvum, y este del gr. ἀρχεῖον, residencia de los magistrados). 1. m. Conjunto ordenado de documentos que una persona, una sociedad, una institución, etc., producen en el ejercicio de sus funciones o actividades. 2. m. Lugar donde se custodian uno o varios archivos. 3. m. Acción y efecto de archivar (‖ guardar documentos o información en un archivo). Entregó la documentación para proceder a su archivo. 4. m. Acción y efecto de archivar (‖ dar por terminado un asunto). El juez ordenó el archivo del caso. 5. m. Inform. Espacio que se reserva en el dispositivo de memoria de un computador para almacenar porciones de información que tienen la misma estructura y que pueden manejarse mediante una instrucción única. 6. m. Inform. Conjunto de la información almacenada de esa manera. 7. m. Col. oficina. 8. m. p. us. Persona en quien se confía un secreto o recónditas intimidades y sabe guardarlas. 9. m. p. us. Persona que posee en grado sumo una perfección o conjunto de perfecciones. Archivo de la cortesía, de la lealtad. FICHERO 1. m. Caja o mueble con cajonería donde se pueden guardar ordenadamente las fichas. 2. m. Inform. Conjunto organizado de informaciones almacenadas en un soporte común. Este mensaje de correo electrónico, incluidos los archivos adjuntos, es para el uso exclusivo de la persona a la que se ha enviado, y puede contener información que sea confidencial o protegida legalmente. Si usted no es el destinatario, o ha recibido este mensaje por error, no está autorizado a copiar, distribuir, o utilizar de alguna manera este mensaje. Por favor notifique inmediatamente al remitente por correo electrónico y suprimir permanentemente este mensaje y los archivos adjuntos. No se otorga ninguna garantía de que este e-mail esté libre de errores o virus. INSTITUTO COSTARRICENSE DE ELECTRICIDAD =��u��y��jV���+��"�f�u맙��j7������ zϮ�˛���m�)z{.��+���j��zw�zZ� yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��
El Tue, 27 Apr 2010 14:27:38 +0200, Karl García Gestido escribió: (...)
Dicho todo esto, el diccionario está bastante bien para ayudar a comprender términos concretos. Creo que cuando un término está bien recogido, asentado en el habla, es lo mejor para usar como regla.
Un diccionario genérico no sirve para entender el significado de un término que se usa en un ámbito concreto. No busquéis en la RAE la verdad absoluta ni términos absolutos porque no los hay. Y si nos metemos en la mundo de las traducciones, hace falta mucho más que un buen diccionario especializado porque muchas veces el propio término en inglés (o en el idioma original) está mal empleado o la frase está mal construida (lo cual suele pasar a menudo porque el programador/ médico/especialista NO es lingüista). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Definiciones de fichero en la web: * Un archivo informático o fichero es un conjunto de bits almacenado en un dispositivo periférico. es.wikipedia.org/wiki/Fichero * ficheros - Agrupación de información que puede ser manipulada de forma unitaria por el sistema operativo de un ordenador. ... www.unipamplona.edu.co/unipamplona/hermesoft/portalIG/home_28/recursos/01_general/09052008/glosario.jsp * Todo conjunto organizado de datos de carácter personal, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización ... www.prodat.es/index.php * Vínculo a 11-las-referencias-en-la-obra-de-fj-gall-una-aportacion-a-los-fundamentos-de-la-frenologia.pdf www.aen.es/biblioteca-y-documentacion/publicaciones-de-la-aen/doc_details/1020--las-referencias-en-la-obra-de-f-j-gall-una-aportacion-a-los-fundamentos-de-la-frenologia * 1) Mueble utilizado para contener fichas. 2) Conjunto ordenado de fichas bibliográficas o catalográficas. www.orienta.org.mx/biblioteca/glosario.html * Todos los datos que se almacenan en tu ordenador se denominan ficheros. El ordenador puede guardar textos, imágenes, piezas musicales, sonidos y demás. Según su contenido, se almacenan con distintos formatos que son reconocidos por sus extensiones, es decir, las letras que aparecen tras el punto. www.ondata.es/recuperar/glosario.htm * Conjunto de información que se almacena para ser consultada o utilizada posteriormente. Normalmente se usa “archivo” como sinónimo. www.hard-h2o.com/diccionario-informatico_d-f.html * fichero que se va a envíar. Para facilitar su selección pulsamos sobre el botón Examinar. Se nos abrirá una ventana desde la que seleccionamos seleccionamos la carpeta/s en las que se encuentra el fichero, así como el propio fichero, una vez seleccionamos pulsamos Abrir: www.eprinsa.net/campus/mod/glossary/showentry.php * Un fichero es un conjunto de datos estructurados que pueden estar almacenados en un soporte de datos de forma que puedan ser tratados o utilizados de forma individual o global. eqaula.org/eva/mod/glossary/view.php * Archivo que contiene un conjunto de registros de datos que se refieren a un mismo asunto. www.nccextremadura.org/eventos2007/bandaancha/glosario.php * Hace referencia a la información que se encuentra en un soporte de almacenamiento informático. Es el trabajo real que realiza cada usuario (textos, imágenes, bases de datos, hojas de cálculo, etc.). Cada uno de ellos se caracteriza por tener un nombre identificativo. ... cibercentros.jcyl.es/webseguridad/palabras.php * ficheros - En informática se denomina FICHERO a todo el conjunto de información (programas o datos) que el ordenador almacena en un disco o cinta de manera ... www.pangea.org/peremarques/glosario.htm * ficheros - Vectoriales: DXF, EPS, PICT, WMF Imágenes: GIF, TIFF, BMP, TGA, PCX, PNG arantxa.ii.uam.es/~pedro/graficos/teoria/Conceptos/ConceptosFundamentales.htm * ficheros - df, du, ls, ln, rm, www.2jr.es/index.php Este mensaje de correo electrónico, incluidos los archivos adjuntos, es para el uso exclusivo de la persona a la que se ha enviado, y puede contener información que sea confidencial o protegida legalmente. Si usted no es el destinatario, o ha recibido este mensaje por error, no está autorizado a copiar, distribuir, o utilizar de alguna manera este mensaje. Por favor notifique inmediatamente al remitente por correo electrónico y suprimir permanentemente este mensaje y los archivos adjuntos. No se otorga ninguna garantía de que este e-mail esté libre de errores o virus. INSTITUTO COSTARRICENSE DE ELECTRICIDAD =��u��y��jV���+��"�f�u맙��j7������ zϮ�˛���m�)z{.��+���j��zw�zZ� yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��
El Tue, 27 Apr 2010 07:24:56 -0600, Sánchez Jiménez José Gabriel escribió:
Definiciones de fichero en la web:
(...) Creo que ha quedado claro >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Definiciones de archivo en la web: * Un archivo informático o fichero es un conjunto de bits almacenado en un dispositivo periférico. es.wikipedia.org/wiki/Archivo_(informática) * #REDIRECCIÓN Richard Kenneth Brummitt es.wikipedia.org/wiki/Archivo_(computación) * Conjunto de documentos históricos que registran las actividades de un estado o una institución; Conjunto ordenado de documentos producto de la ... es.wiktionary.org/wiki/archivo * Por archivos se entiende, en la música, el conjunto de partituras y documentos archivados y conservados relacionados con ésta, como por ejemplo ... es.wikipedia.org/wiki/Archivos_(música) * Unidad de información almacenada en el disco con un nombre específico. Puede contener datos en código máquina, necesarios para la ejecución de un programa, o información común y corriente procesada por el usuario. ... www.zonagratuita.com/curiosidades/glosarioNET/A.htm * Conjunto de información, como un documento o un programa que suele almacenarse en un disco para ser leído por el ordenador. Se puede denominar también fichero. www.radiosantacruz.icrt.cu/pagina/glosario-informatico-a-d.htm * (File)- En fotografía digital, cualquier conjunto de datos se conoce con el nombre de archivo. Las distintas maneras de organizarlos dan lugar a tipos muy diferentes entre sí. guia.mercadolibre.com.co/pequeno-diccionario-fotografia-digital-7743-VGP * Unidad significativa de información la cual puede ser manipulada por el sistema operativo de un ordenador debido a que tiene una identificación única formada por un "nombre" y un "apellido". ... www.moraldonetworks.com.ar/info/reference/glossary_a.htm * archivos - el conjunto de posts o artículos de un blog dispuestos en una sola página. Pueden ordenarse por categoría, fecha…etc. www.blogmundi.com/glosario-de-blogging/ * Colección de registros almacenados siguiendo una estructura homogénea. www.soeduc.cl/apuntes/basededatos.doc * Conjunto de bytes estructurados que puede contener tanto ficheros como programas. www.hard-h2o.com/diccionario-informatico.html * los ítems de contenido pueden ser archivados y manipulados desde el administrador. El módulo del archivo provee un método para mostrar estos ítems de contenido en el sitio Web. edu.jccm.es/joomla15/index.php/sobre-joomla/informacion-general/18-glosario-de-terminos-usuales-en-joomla.html * adjunto Archivo que se incluye en un correo electrónico, como puede ser un documento o una foto. www.fundacioncnse.org/panda/glosario.html Este mensaje de correo electrónico, incluidos los archivos adjuntos, es para el uso exclusivo de la persona a la que se ha enviado, y puede contener información que sea confidencial o protegida legalmente. Si usted no es el destinatario, o ha recibido este mensaje por error, no está autorizado a copiar, distribuir, o utilizar de alguna manera este mensaje. Por favor notifique inmediatamente al remitente por correo electrónico y suprimir permanentemente este mensaje y los archivos adjuntos. No se otorga ninguna garantía de que este e-mail esté libre de errores o virus. INSTITUTO COSTARRICENSE DE ELECTRICIDAD
Hola :) On Monday 26 April 2010 23:39 Carlos E. R. wrote
On 2010-04-26 23:24, Karl García Gestido wrote:
O Luns 26 Abril 2010 22:26:02 Carlos E. R. escribiu:
No, no hemos usado la edición enmendada. Hemos usado esa, otras, y otras fuentes. Es una discusión antigua, llevamos años con esto.
Lo comento porque tener una autoridad central es muy útil, pero no debería ser algo sagrado. De hecho, gran parte de la terminología que usamos no está aprobada.
En la 22ª edición fichero no es lo mismo que archivo. No me queda claro si eso es como debe de ser o no, personalmente encuentro confusas las definiciones de cada edición :S ... pero, con ánimo de maldad >:-) , en este caso no podemos aludir a la RAE para indicar que ambos términos son lo mismo.
fichero.
1. m. Caja o mueble con cajonería donde se pueden guardar ordenadamente las fichas. 2. m. Inform. Conjunto organizado de informaciones almacenadas en un soporte común.
Artículo enmendado (23ed)
1. m. Caja o mueble con cajonería donde se pueden guardar ordenadamente las fichas. 2. m. Inform. archivo (‖ conjunto de información).
archivo.
5. m. Inform. Espacio que se reserva en el dispositivo de memoria de un computador para almacenar porciones de información que tienen la misma estructura y que pueden manejarse mediante una instrucción única.
5. m. Inform. Conjunto de información almacenada en la memoria de una computadora que puede manejarse con una instrucción única.
La definición actual de archivo es falsa o absurda. La enmendada tampoco tiene sentido. ¿Memoria? Los archivos no están en memoria, están en dispositivos de almacenamiento permanente, para darles el nombre correcto a los discos y similares.
También hay que sumar esto: "[...] y que pueden manejarse mediante una instrucción única." Cualquier dispositivo y/o fichero (ya, ya sé que en Unix todo tiene su representación como fichero, pero quiero distiguir entre una representación lógica y el dispositivo físico) se puede manejar mediante una instrucción única, como ejemplo: ls -lh /dev/sda ls -lh /etc/fstab Luego lo de manejar mediante instrucción única ... no deja nada claro ni distintivo :( Por lo menos IMHO.
La de fichero actual tiene sentido, pero la enmendada es extraña.
Ahora sé por qué tiré por Ciencias ;) Rafa -- "We cannot treat computers as Humans. Computers need love." Happily using KDE 4.4.2 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-04-27 08:40, Rafa Grimán wrote:
También hay que sumar esto: "[...] y que pueden manejarse mediante una instrucción única."
Cualquier dispositivo y/o fichero (ya, ya sé que en Unix todo tiene su representación como fichero, pero quiero distiguir entre una representación lógica y el dispositivo físico) se puede manejar mediante una instrucción única, como ejemplo:
ls -lh /dev/sda
ls -lh /etc/fstab
Luego lo de manejar mediante instrucción única ... no deja nada claro ni distintivo :( Por lo menos IMHO.
No, no lo es. ¿Que es una instrucción, para empezar? ¿Una instrucción de assembler? ¿Un comando de shell? ¿Un comando externo?
La de fichero actual tiene sentido, pero la enmendada es extraña.
Ahora sé por qué tiré por Ciencias ;)
:-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvXRyUACgkQU92UU+smfQVk9QCfcz42iDPhvCdPiVA5wVldvSyo KdIAn0cf6UvA7M/ySJEGU5fhMiNxgIuE =7PeR -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Mon, 26 Apr 2010 23:24:58 +0200, Karl García Gestido escribió:
O Luns 26 Abril 2010 22:26:02 Carlos E. R. escribiu:
No, no hemos usado la edición enmendada. Hemos usado esa, otras, y otras fuentes. Es una discusión antigua, llevamos años con esto. Lo comento porque tener una autoridad central es muy útil, pero no debería ser algo sagrado. De hecho, gran parte de la terminología que usamos no está aprobada.
¿"Usamos", quienes? ¿La gente de la calle, los traductores, los profesionales...? No se trata de nada "sagrado" sino de mantener una coherencia en las traducciones. Ten en cuenta que hay muchos equipos de traducción independientes (KDE tiene el suyo, GNOME también, el Translation Project gestiona algunos programas independientes) y se intenta mantener un mismo estilo o línea de traducción para que, por ejemplo, en todos los menús se vea "Archivo/Editar" en lugar de "Fichero/Modificar", por poner un ejemplo. Nadie te puede decir que "Fichero/Modificar" esté mal, pero obviamente, no es práctico si tenemos en cuenta que el objetivo es que el usuario sepa lo que hacen esos elementos. Tampoco nadie te puede decir que "ordenador" no sea un término correcto (está en la RAE) pero se intenta evitar el uso de modismos. No se trata pues de algo "sagrado" o "intocable", sólo "lógica", pura lógica y nada más.
En la 22ª edición fichero no es lo mismo que archivo. No me queda claro si eso es como debe de ser o no, personalmente encuentro confusas las definiciones de cada edición :S ... pero, con ánimo de maldad >:-) , en este caso no podemos aludir a la RAE para indicar que ambos términos son lo mismo.
Menudo lío os estáis haciendo con lo de fichero/archivo X-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-04-20 19:20, aux wrote:
On Martes 20 Abril 2010 17:49:20 Camaleón escribió:
las particiones extendidas dan mejor rendimiento que con LVM?
¿Ein? Las extendidas, o mejor dicho, las lógicas, son prácticamente iguales que las particiones primarias. La única diferencia es cómo se guardan la dirección de comienzo y de final. Una vez que el kernel sabe esto, son exactamente iguales. Las LVM la cosa es bastante distinta, hay una capa intermedia. Un trozo de partición puede estar incluso en un disco y el siguiente en otro...
Sabes si son mas fáciles de recuperar ante algún fallo?
Indudablemente, LVM tiene una capa más de complicación. Creo que te hace falta leer sobre lo que son las particiones, y luego sobre lo que es LVM. :-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAkvN9XQACgkQja8UbcUWM1xILgEAl5ZoetR2mnyAmd4wMG0X79WO NBcEu1fbVeqhKbbSRBUA/A59TZgNmhWzyMKnkj1ux94x/aOheCnrD5gKMt9Lzopp =Msfh -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (8)
-
aux -
Camaleón -
carlopmart -
Carlos E. R. -
Karl García Gestido -
Lluis -
Rafa Grimán -
Sánchez Jiménez José Gabriel