#177 Desde los patrones de diseño, consecuencia del desarrollo orientado a objetos, se puede decir que el desarrollo software cumple los criterios del punto 2.
El resto de tecnicas anexas a cualquier ingeniería funciona en el mismo sentido al mismo nivel. Hablo de gobernanza, gerencia, gestión de proyectos, etc.
#41 Hombre por la parte que me toca... yo en esa epoca estaba en el Colegio Mayor, y no compraba ni un periódico....porque en el Colegio los tenía todos para leerlos gratis. Y bien que me los leía todos a conciencia.
#50 Es lo ultimo que dices.
Hace unos 20 años, cuando empezó a popularizarse el formato MP3, recuerdo a un amigo que me decía sorprendido: "acaba de salir una tecnología que es capaz de comprimir 13 CDs de audio en un solo CD-ROM! El unico problema es que tarda 12 horas en comprimir un solo CD, y además necesitas un 486 para reproducir el fichero"
En esa epoca (sería el año 1991 o 1992), el 486 era un PC de gama media/alta.
#47 Solo para compresión SIN perdidas. Que no es el caso.
#48 Te has pasado con la contestación, y encima eres tú el que no tiene razón. Los límites de entropía que mencionas se refieren a la compresión/codificación SIN pérdidas.
Todos los métodos prácticos actuales de compresión de vídeo son CON pérdidas, y ahí sí, aun no está todo inventado y se puede comprimir mucho más. Todo depende del algoritmo que uses para decidir lo que quieres "perder" al comprimir.
Así que sí, a base de tirar de CPU, aun podemos comprimir tanto como queramos. Depende de la complejidad de nuestro algoritmo.
#56 La entropía también se aplica a la compresión con perdida: que no es más que agrupar bloques de información similares bajo un mismo símbolo. El porcentaje de información perdida define el umbral que estás dispuesto a considerar aceptable. Al margen de eso, es exactamente lo mismo.
Y no, tirando de CPU no puedes comprimir tanto cuanto quieras. No puedes comprimir un mega en un bit, salvo que estés dispuesto a perder el 100% de la información claro: y eso no tiene nada que ver con el algoritmo, ni con el uso de CPU.
#63 se aplica en el sentido de que una compresión lossy es una reducción de la entropia hecha a propósito. En una compresión lossless efectivamente la entropia determina tu límite. En una lossy, es simplemente una propiedad, pero no es mi factor limitante, ya que la entropia de la entrada y de la salida son distintas. No entiendo su relevancia para hablar de un límite teórico para la efectividad de compresión lossy de vídeo
#68 Sí es un factor limitante y el proceso es exactamente el mismo: sin extenderme mucho, puedes pensar en la compresión con pérdida como en el siguiente proceso (dicho rápido y mal, pero equivalente a efectos prácticos):
1) Aplicas un filtro a la entrada para eliminar la información que no te interesa o agrupar/reducir la granularidad/precisión de la menos relevante.
2) Aplicas compresión.
Como ves, lo que determina la pérdida es el filtro aplicado a priori, el resultado del filtro (tu entrada para compresión) tiene cierta entropía y supone un límite como siempre. La compresión con pérdida trata de encontrar mejores filtros que eliminen/agrupen información no relevante para la vista u oído humanos de forma que el impacto en la percepción sea mínimo. Una vez eliminado todo lo que los sentidos humanos no perciben, lo que queda, que es bastante, se comprime con las mismas limitaciones de siempre (las cuales, son matemáticas y absolutas).
En resumen: la compresión con perdida es solo añadir un filtro que transforma la entrada antes de una compresión sin pérdida.
#81 En efecto; por eso la afirmación a la que respondía en mi primer comentario era falsa: no puedes comprimir todo lo que quieras tirando de CPU y siempre tienes un límite absoluto; una vez que has descartado la información que no te interesa estás tan limitado como siempre.
#84 ese comentario original de que podías reducir tanto como quisieras es obviamente falso. Pero te has metido en un berenjenal tu solo añadiendo conceptos que aplican a compresiones lossless y luego te has agarrado a un clavo ardiente para justificar el por que ese concepto era aplicable en este caso y por el camino dejando mensajes (algunos escritos de manera turbia, otros directamente falsos) que lo único que hacen es complicar aún más un tema que ya de por si es complejo para gente que no esté familiarizada
#114 Y lo grande o pequeña que es esa diferencia, viene determinada por la entropía del original.
Formalmente lo que estás haciendo es una descomposición incremental de la señal, no deja de ser otra forma de filtrado.
#63 por cierto, compresión lossy no es agrupar bloques de información similares bajo un mismo símbolo, eso solo es el último paso. Cuando aplico un MDCT a un archivo de sonido para eliminar ciertas frecuencias y crear un mp3, no estoy agrupando bloques de información similares. Estoy eliminando información (y entropia), pero lo estoy haciendo de una forma muy específica basándome en las limitaciones del oído humano. Lo mismo cuando en compresión de imagen me baso en mantener información de luminancia y desechar parte de la información de crominancia. No es la similitud de los símbolos la que me permite hacer eso, sino la distribución de conos y bastones en el ojo humano limitando nuestra visión en color
#25 me parece que ha preguntado por la paridad en el estudio de desarrollo, no en el argumento del juego.
Vamos que si es vuestro grupo estáis equilibrados en género o no.
#131 Supongo que en su estudio han contratado a los mejores que han podido, sin importar el género, como solemos hacer en todos los estudios, no conozco un solo sitio donde digan, o que portfolio tan bueno tiene esta chica, es increíble, se ajusta perfectamente a lo que buscamos, pero ups,es chica, tenemos que contratar a este tío que bueno, en unos meses esperemos que se adapte a lo que buscamos..
Es un poco ridículo.
#27 Ubuntu incluye y da soporte a ZFS de serie desde hace un par de releases, como ya dije en #28
En cuanto a lo de RedHat y ZFS que mencionas, es completamente falso. Red Hat no da soporte a ZFS, ni siquiera pagando. De hecho, estan desarrollando su propio sustituto, Stratis (https://stratis-storage.github.io/). Sustituto a nivel funcional, Stratis no es un filesystem nuevo, sino un conjunto de tecnologías ya existentes, integradas (XFS/LVM/RAID/CRYPT)
Y por ultimo, sobre lo de la documentacion, revisa la documentacion de Oracle sobre ZFS, hay toneladas, y de excelente calidad.
#29 #27 BTRFS es una puta mierda, casca como nada, no tira en Raid5 y esta repleto de inconsistencias. Si hasta hace dos dias no tenia ni FSCK.
Y con XFS reza para que no tengas un corte de luz. Mira, ni de hostias supera XFS a ZFS. Ni borracho.
El TRIM serviria hace ocho años, hoy todas las SSD lo hacen via controlador, tengo un OpenBSD con FFSv1 en una tan ricamente.
Los de GNU deberian adaptar o Hammer, o BcacheFS.
#38 Con lo del XFS de doy toda la razón, ya van 2 veces que he tenido que reparar el el sistema de archivos mi NAS casero por cortes de luz.
Sobre lo de Raid ya comente que con ZFS mejor.
#50 Pues debo de tener mucha suerte porque el servidor de archivos de la ofi que utiliza BTRFS lleva funcionando como 2 años sin dar un solo problema y haciendo snaphots... y es que servidor que alberga las copias de seguridad también utiliza BTRFS y sin problemas desde hace un año. (Solo reinicio esos cacharros tras una actualización mayor).
#70 Mi experiencia en con btrfs, y un montón de containers lxc. Acabé migrándolos a un disco con ext4, porque el rendimiento era horrible, notando la diferencia desde el primer día.
#29 Joer es cierto Red Hat ha dejado de dar soporte a ZFS. Hace un par de años lo daba de hecho un compañero había utilizado ZFS con Red Hat para un tema empresarial. Parece ser que ha dejado de dar soporte en la version 7.4. Entonces esa es otra razón para no usar ZFS
#15 Ubuntu incluye ZFS de serie desde hace un par de releases.
#27 Ubuntu incluye y da soporte a ZFS de serie desde hace un par de releases, como ya dije en #28
En cuanto a lo de RedHat y ZFS que mencionas, es completamente falso. Red Hat no da soporte a ZFS, ni siquiera pagando. De hecho, estan desarrollando su propio sustituto, Stratis (https://stratis-storage.github.io/). Sustituto a nivel funcional, Stratis no es un filesystem nuevo, sino un conjunto de tecnologías ya existentes, integradas (XFS/LVM/RAID/CRYPT)
Y por ultimo, sobre lo de la documentacion, revisa la documentacion de Oracle sobre ZFS, hay toneladas, y de excelente calidad.
#29 #27 BTRFS es una puta mierda, casca como nada, no tira en Raid5 y esta repleto de inconsistencias. Si hasta hace dos dias no tenia ni FSCK.
Y con XFS reza para que no tengas un corte de luz. Mira, ni de hostias supera XFS a ZFS. Ni borracho.
El TRIM serviria hace ocho años, hoy todas las SSD lo hacen via controlador, tengo un OpenBSD con FFSv1 en una tan ricamente.
Los de GNU deberian adaptar o Hammer, o BcacheFS.
#38 Con lo del XFS de doy toda la razón, ya van 2 veces que he tenido que reparar el el sistema de archivos mi NAS casero por cortes de luz.
Sobre lo de Raid ya comente que con ZFS mejor.
#50 Pues debo de tener mucha suerte porque el servidor de archivos de la ofi que utiliza BTRFS lleva funcionando como 2 años sin dar un solo problema y haciendo snaphots... y es que servidor que alberga las copias de seguridad también utiliza BTRFS y sin problemas desde hace un año. (Solo reinicio esos cacharros tras una actualización mayor).
#70 Mi experiencia en con btrfs, y un montón de containers lxc. Acabé migrándolos a un disco con ext4, porque el rendimiento era horrible, notando la diferencia desde el primer día.
#29 Joer es cierto Red Hat ha dejado de dar soporte a ZFS. Hace un par de años lo daba de hecho un compañero había utilizado ZFS con Red Hat para un tema empresarial. Parece ser que ha dejado de dar soporte en la version 7.4. Entonces esa es otra razón para no usar ZFS
#28 no lo sabía. Parece que en la última, como "experimental" y con dudas acerca de la legalidad.
#26 Buenisimo, he llorado de risa. La idea original es de Monty Python, cómo no:
#26 acabas de dar en el clavo. La forma de fomentar el movimiento de capitales es con obra pública. Así no dependes de que la gente haga lo que debe con el dinero regalado.
Pero eso es sólo la mitad de la solución.
La otra parte sería..."pero quién lo paga?", Y la respuesta está más que clara: los impuestos a los ricos y las grandes empresas.
#133 Hombre, como ingeniero industrial con 35 años de experiencia te diría: que sea una materia científica (aplicación del método científico), que sea lo suficiente madura como para tener un amplio cuerpo de conocimientos procedimentado (sistemática), y que sea aplicada (no teorica).
La ingeniería informática cumple los criterios 1 y 3, pero en el segundo esta un poco mas verde comparada con el resto de ingenierías.