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