EDICIóN GENERAL
meneandro

meneandro

En menéame desde septiembre de 2007

6,21 Karma
16K Ranking
12 Enviadas
0 Publicadas
3.683 Comentarios
0 Notas

El iPhone 6 pierde un 40% de rendimiento al parchearse la vulnerabilidad Spectre [127]

  1. #20 Si y no. Cuando tu circuitería te hace el trabajo rápido y "bien" y tienes que sustituír parte de lo que te hace la circuitería por una versión software que encima al hacer las cosas como deberían hacerse hace más chequeos y por lo tanto todo será más lento (y además añadirá una carga extra de proceso que antes no tenía), la pérdida de rendimiento es real y grande.

    Para que lo entiendas, imagínate que hay una vulnerabiliel famoso modo 7 de snes (si, un chip específico que realizaba por hard escalados y rotaciones de imágenes), imagínate lo costoso que sería emular eso por software por una cpu tan débil como la que tenía la máquina. ¿Es culpa de que no hayan optimizado el software? quizá se puedan hacer algoritmos de escalado y rotación más eficientes, pero nunca comparables a hacerlos directamente con el chip.
  1. #8 ARM vive de licenciar su arquitectura. Que el diseño base no sea vulnerable (y ya se sabía que algunos si que lo eran) no implica que las "mejoras" o "añadidos" de terceros no provoquen que si lo sea.

Intel AMT tiene una brecha de seguridad, millones de portátiles corporativos son vulnerables [77]

  1. #16 #2 #3 #13 En realidad esas bajadas de rendimiento se notarán en escenarios concretos y con mucha carga (al menos todoas las pruebas lo indican así). O sea, en escenarios de servidor y virtualización. Al usuario corriente le tocará pero apenas notará diferencias y en momentos muy concretos (salvo que te dediques precisamente a usar equipos virtuales o a tareas de alta carga o cómputo científico, y aún así no "perderás dinero" tras los parches, cosa que si pasará en una empresa).

    Sobre amd, los parches que han de aplicar son los "menos graves", aquellos donde se puede corregir sin prácticamente deteriorar el rendimiento. Que no es lo mismo detectar un caso y poner un código que evite que se pase por ahí que anular parte de tu circuitería hardware que acelera ciertos procesos y tener que hacer los mismos bien y por software. Que todos tienen lo suyo, pero por mucho que se empeñen en insinuarlo, no es ni de lejos lo mismo.

    A veces también compras x y consigues sin saberlo un X+20% e incluso más. Que se lo digan a overclockers con suerte... pero claro, eso ya no cuenta...

Correo de responsable de AMD a los desarrolladores del kernel Linux [ENG] [57]

  1. #31 Es sólo para probar (con todas las funcionalidades, pero eso si, a velocidad usb/dvd, que puede ser un tanto lento comparado con un ssd o un disco duro y una instalación normal, salvo que realices una instalación en tu propio disco o en una máquina virtual, claro). El hard tiene que ser muy muy nuevo y/o de algún fabricante raro para que no esté soportado sin instalar nada, al menos en las distros más populares (tipo ubuntu).

    Evidentemente, se arranca desde un dispositivo que no es el disco duro, tu windows sigue ahí sin tocar (una vez más, salvo que instales en paralelo junto al windows, donde no se toca el windows pero si se mantiene ahí o si lo haces en una máquina virtual, que al fin y al cabo no es más que un fichero gordo) y los cambios no son permanentes, son "una sesión" por así decirlo.

    La programación no es necesaria para probar ni para usar linux en el día a día (mucha gente lo usa para cosas básicas sin tener ni puñetera idea de informática, así en general). La ventaja de linux es que tienes todo a mano para si en algún momento te interesa puedas hacerlo, si quieres compilarte, examinar, jugar y manipular tú mismo cualquier aplicación que esté en sus repositorios (el propio kernel incluído) puedas hacerlo.

    El positivo es probarlo por ti mismo y ver si de alguna manera puede ganarse un hueco en tu vida.

Así se hunde una firma, según el CEO de GoPro: “Quisimos ser lo que no éramos” [148]

  1. #107 Lo que quiero decir es que no es lo mismo un tercio de 1000 que de 100.000, si pierdes 333 te recuperas rápido, si pierdes 33.000 (y la confianza de los inversores) igual tienes un problema.

    Y bueno, es un win si tienes ingresos suficientes. Si has tenido que recortar tu plantilla es porque tienes que atajar deudas y las deudas se provocan por dos cosas, o por muchos gastos o por muy pocos ingresos (o una mezcla de ambas). Si tu empresa se echa un pedo mayor que el culo y los inversores ven que eres humo no compran y te quedas sin inversiones. Y salvo que tengas un sólido negocio detrás y puedas recuperarte...

    Por otro lado, este tipo de negocios se sustentan en la gente, tienes que correr mucho hacia adelante y seguir "engañándoles" para que piensen que no hay otro producto como el tuyo. Si ven que te fumas su dinero y que hay otros productos igual de buenos mucho más baratos podrían sentirse estafados y buscar alternativas mañana. Y no estoy seguro, pero creo que gopro es un "monocultivo", no ha diversificado nada, si la gente deja de comprar gopro...
  1. #76 Pero es que los chinos no dedicaron muchos años a crear un ecosistema de productos integrados (y muy cerrados). Sin IOs y MacOS apple sería uno más. Fíjate cuán poco tardó apple en capar la posibilidad de que hubiera clónicos Mac o iPhone (por mucho que pudiera ganar una pasta vendiendo SOs por separado de su hardware) y lo que se la sopla que hubiera copias de ipod, ipad, iPhone, macbook air, etc.
  1. #17 Estoy de acuerdo a grandes rasgos.

    Pero... dime qué no se pueda hacer con algo que no sea apple...

    Porque realmente lo que apple vende es "con nuestro ecosistema de cosas sólo podrás hacer cosas desde nuestros paratos y para nuestros paratos; quizá alguna funcionalidad novedosa temporalmente que poco tardarán en copiar y mejorar los demás, quizá de manera más sencilla hasta que otros lo copien y mejoren, quizá sin tantos problemas hasta que nos acomodemos o hasta que empecemos a sacar productos de bajo coste para copar otros mercardos y empiece a sudárnosla (más aún)"
  1. #15 Depende del tamaño de tu empresa. Cuando eres 3 personas, que caiga el 33% es perder una. Cuando has crecido un 150% y eres 9 personas, que se caiga el 33% ya es caerse 3. Y si te fijas, caerse 3 es caerse el número de personas que habían originalmente antes de que la empresa cayera. Como ves, el 33% antes y después de crecer es muy diferente.

    Que si, que aún quedarían 6 personas, pero igual con una empresa tan grande, tener a 6 personas no permite ser eficiente y mantenerla.

Actúa ahora para salvar la internet como la conocemos - Tim Berners-Lee [62]

  1. #49 A ver, que las comunicaciones (todas) vayan por un mismo medio (por ejemplo, un cable de fibra transoceánico) y haya que separar servicios de alguna manera no implica faltar a la neutralidad de la red. Fallas a la neutralidad de la red cuando dentro del servicio de datos de internet y de manera interesada beneficias ciertos paquetes de datos sobre otros cuando deberías tratarlos a todos igual. Una VPN no es internet, va por internet, pero se trata de dos puntos distantes que en realidad pertenecen a la misma intranet. Y la calidad de tu VPN depende de la calidad y velocidad de tu conexión, no por ser una VPN tienes más prioridad sobre el resto de tráfico de internet. Las comunicaciones de voz tipo VoIP y demás se basan en protocolos que están diseñados por y para el tráfico de internet pero de nuevo dependen de tu conexión, si tienes una conexión de mierda adaptan la calidad a esa conexión de mierda. Si quieres telefonía IP de calidad estoy seguro de que puedes pagar una conexión de calidad.

    Lo que tiene que mejorar es toda la parte de infraestructuras, la calidad de internet es una mierda porque o se dimensionan mal, o no se quiere gastar más pasta porque no sale rentable, no son motivos técnicos suficientes hoy en día (mira Japón, tienen la mayor densidad mundial de población con móviles e internet y las mejores comunicaciones, no hay problemas de saturación de redes y van a unas velocidades de la leche). El problema no es ni nunca ha sido la neutralidad de la red.
  1. #35 Dices esto como si fuera bueno, como si se hubiera abierto el mercado y hubiera competencia y pudieran competir y eso conllevara bajar precios y demás...

    Al contrario, esto supondrá matar competencia. Las grandes ISP que puedan contratar paquetes con las grandes productoras de contenidos tendrán el cotarro de proveer internet bajo control. Ahora tú podrías montar tu "fairISP" y competir con las demás bajo las mismas reglas y con los mismos compromisos. Mañana las productoras de contenidos manejarán el cotarro porque sólo cederán sus contenidos (por una pasta cuantiosa) a las cuatro ISP de su elección y tu fairISP aunque sea justa y trate todos los contenidos por igual resultará que no tendrá contenidos o la calidad de acceso a los mismos será paupérrima (si detectan que un paquete suyo se va a ir a una red no controlada por las ISP de sus amores, matarán el paquete o harán un cuello de botella interesante hacia tu lado y por lo tanto irás como el culo). Porque los contenidos viajan por internet, no saltan directamente a tu ISP.

    O sea, si piensas que esto no afectará a otras ISPs, que será un comportamiento o unos efectos localizados eres muy ingenuo.

AMD abre el código Vulkan de AMDGPU-PRO [37]

  1. #33 Digamos que aún vulkan no es nada. OpenGL es el estándar de facto aún, y en empresas gordas, de esas que llenan granjas con tarjetas nvidia para render, procesado de datos o lo que sea, tiran de OpenGL y CUDA. ¿Dónde va a poner la pasta nvidia? que se estén disparando un tiro en el pie el tiempo dirá.

    Por otro lado, nvidia no es tonta, las herramientas que ha liberado AMD son libres y abiertas. Esto es, funcionan en la competencia (al contrario que las de nvidia, que suelen funcionar sólo en su hardware). Si los de enfrente te hacen el trabajo...
  1. #34 No basta con que sea abierto. .NET es abierto, pero MS puede cambiarlo cuando quiera. Java como implementación de lenguaje es abierto, pero lo controla ORACLE.

    OPENCL es abierto, si, pero no está atado a una empresa, sino a toda la industria (o a todos los que quieran, el grupo khronos está abierto a recibir nuevos miembros, peticiones, etc. para mejorar sus estándares. Y si, hay varias implementaciones del estándar.

    Y digo abierto porque ninguno es libre. No están atados a una licencia que permita su modificación por cualquiera, están atados a compañías o a organizaciones que controlan y velan por su desarrollo.

    Si programas OpenCL con nvidia lo haces con el propietario si o si. Noveau no está lo suficientemente maduro para hacer openCL (porque es un esfuerzo altruísta y de ingeniería inversa brutal, bastante tienen con dar soporte a la aceleración 3D), así que es la única forma.

Actúa ahora para salvar la internet como la conocemos - Tim Berners-Lee [62]

  1. #8 ¿Y quién te garantiza que "fairISP" no sea comprada, vendida o cambie de opinión? ¿y quién te garantiza que la gente no prefiera pagar 20€ menos dado que "total, sólo accedo a FB, Twitter, gmail y youtube, mientras me garanticen que ahí voy a navegar bien aunque el resto de cosas se arrastren..."
  1. #9 QoS es para servicios críticos y para ser usada en intranets, no debería usarse indiscriminadamente a nivel internet por nadie para conseguir nada.

    O sea, si tu eres youtube, usas de puertas adentro QoS para garantizar que todos los vídeos van por igual (que ninguno se chupe todo el ancho de banda dejando a los demás colgados). Si eres un mega, para garantizar la calidad de tus descargas premium (y dar tu mejor esfuerzo en el resto). Si eres una universidad para garantizar ancho de banda a tus investigadores por encima de tus usuarios universitarios y de administración. Pero como digo, de puertas adentro, y para mejorar el servicio. A nivel ISP estas prácticas deberían estar prohibidas (que sabemos que se dan igualmente, pero son contrarias a la neutralidad de la red y denunciables, pregúntale a comcast).
  1. #3 ¿Para que qué tecnología avance? ¿la de las multis o grandes startups con muchísima pasta de por medio -o sea, las promovidas por las multis-? porque una pequeña empresa que empiece no va a poder competir con una grande en condiciones normales, imagínate si además empiezas a ponerles barreras (ya pagará un precio mayor por ancho de banda porque contratará al por menor, si encima para que ese ancho de banda le rinda lo mismo tiene que pagar otro extra...). Da igual que tu aplicación sea el triple de rápida y de eficiente y vaya mejor y haga mejores cosas, etc. que si el mayor factor limitante en cuanto a velocidad es la red y la controla otro tu aplicación va a ir siempre como el culo y la de los otros va a ir "bien". Eso si no te capan directamente con cualquier excusa.

AMD abre el código Vulkan de AMDGPU-PRO [37]

  1. #27 Pues no debería. No es lo mismo CUDA (que cuando nvidia se vaya al carajo o deje de dar soporte vía drivers en tarjetas más nuevas todo lo que hayas invertido en programas que lo usen se quedará estancado, no pudiendo aprovecharlo en el futuro) que OpenCL. De hecho, hay mucho interés puesto en conversores CUDA -> OpenCL.

    Linux no te lo pone difícil, quien te lo pone difícil son las empresas que desarrollan para una plataforma en mente y se olvidan de los estándares. Haciendo software portable usando los estándares existentes puedes cambiar de plataforma y no atarte a ningún fabricante concreto. Ciertas empresas te lo ponen fácil y crean estándares de facto, pero cuando tienen el mercado se cierran y te atan al mismo (al precio que pongan, porque no hay competencia... por culpa de los propios usuarios, esos que piensan como tú dices, malgastando el dinero y recursos de otros porque total, se la repanpinfla). Luego hay compañías como amd (la actual amd, he de decir), que sacan toda una serie de herramientas libres y abiertas para hacer las mismas cosas, para crear un ecosistema completo y potente que se desarrolle de forma sana (al fin y al cabo les conviene que la gente use sus herramientas y su hardware), pero donde cualquiera se pueda sumar. El beneficio al final es para todos, a AMD porque la comunidad y otras compañías lo expandirán, pulirán sus herramientas, añadirán mejoras, sacarán jugo a su hardware añadiendo nuevas posibilidades e ideas que ellos no ofrecen (porque están más enfocados a otras indústrias o entornos), etc.
  1. #26 No hace falta hacer nada*, el soporte está integrado en el kernel y los drivers vienen con el SO**.

    * Salvo en el caso de que tengas una vega, donde hay soporte limitado debido a que aunque desde el lanzamiento el driver completo es opensource y está disponible para cualquiera, aún están ciertas partes integrándose en el kernel. Aún así, siendo valiente todavía puedes instalar todo lo necesario desde repositorios de terceros (salvo que quieras compilarte tú el último kernel que aún no se ha lanzado, con todos los riesgos que ello conlleva). La única opción para un usuario común es esperar, en Abril junto con las versiones gordas de ciertas distros (fedora 28 y ubuntu 18.04 y derivados) ya debería estar todo en su sitio y de manera más pulida y estable. Antes de eso existirán backports a distros actuales casi con total seguridad, las betas de las anteriores y el siempre útil proceso de compilarte tú mismo lo que necesites. O utilizar el driver privativo hasta ese entonces.

    ** Los drivers por lo demás están listos. Todo este "retraso" viene por el hecho de que amd está compartiendo cada vez más código entre los desarrollos de windows demás sistemas operativos, y buena parte de algunas funcionalidades necesarias para que todo funcione está tratándose de integrar en el kernel. Para que te hagas una idea, llevan al menos año y medio puliendo cosas para que esto sea posible, dado que desde el kernel de linux les rechazaron la petición original porque el código que querían integrar chocaba contra muchas de las políticas de desarrollo, mantenibilidad y de calidad que se exigen (si todo el mundo pusiera lo que quisiera y como quisiera dentro del kernel, se convertiría en un infierno inmanejable e inauditable). Entre otras cosas, en lugar de usar las facilidades dadas por el kernel para muchas cosas añadían las suyas propias (compartir código hace que todo sea menos dado a contener errores y es mucho más limpio que si todo el mundo mete código para hacer lo mismo), el código necesitaba una limpieza a profundidad (mucho código escrito para plataformas más viejas, en desuso, o sin uso), una auditoría de seguridad hecha por la gente del kernel encontró bastantes agujeros, etc. Sin el retraso que les ha supuesto revisar, refactorizar, etc. todo el código, sería plug & play tal y como tú dices. Y dentro de unos meses, como dije antes, así será.

    PD: El soporte a futuras tarjetas gráficas será directo y a la par que el lanzamiento porque ya todo el trabajo "duro" de todos estos años para ponerse al día estará hecho. De hecho, los portátiles con la nueva apu basada en ryzen y vega está casi listo (como en el caso de las vega, llegará en el próximo kernel y luego tardará tanto en implantarse como lo que tarden las distros en ofrecerlo).
  1. #20 Hace años que hay drivers libres. Pero AMD no tiene la cantidad de gente que tiene intel para ponerse al día de un día para otro. Y aún así van sacando una cantidad de trabajo impresionante adelante. A partir del kernel 3.16 (o mediados del próximo año), aparte de funcionar y funcionar bien y con buen rendimento, estarán prácticamente a la par que sus equivalentes en windows (y me refiero a funcionalidades, no sólo en cuanto a rendimiento, que en cuanto a eso ya lo están).
  1. #19 #16 AMD lleva mucho tiempo aportando herramientas libres, el problema es que hasta hace poco el soporte en cuanto a drivers y a linux dejaba que desear. Pero creo que este año que viene por fin estará todo en su sitio (y me refiero no sólo a drivers en si, sino soporte a HSA, OpenCL, etc). Entre eso y las herramientas libres que ya existen (toda la iniciativa "Open") será una plataforma de desarrollo de un nivel importante (que siempre habrá que pulir, pero los desarrolladores por fin tendrán todo a su disposición, libre, con documentación y soporte).
  1. #10 Mesa es una implementación libre de OpenGL. Los drivers libres soportan mesa y mesa da una serie de infraestructuras que facilitan y ayudan a la creación de nuevos drivers (o sea, se trata de enganchar tu hardware a las partes de mesa que se comunican con el SO y las aplicaciones para dar soporte a las funciones OpenGL que estas últimas usan; los drivers privativos tienen que montarlo todo completo).

    Wine no es un emulador. Son unas librerías que se encargan de sustituír las dlls de windows de manera que sean compatibles con las originales y el software que las use funcione en otros entornos que no sean windows. De hecho, otros proyectos como react os (que esto es un SO windows compatible escrito desde cero) las usan.

    Gallium Nine es una reimplementación de DX9 para hacerlo funcionar sobre las infraestructuras gráficas de linux. Puede verse como wine, reescribir las dlls necesarias para que cualquier aplicación escrita para usar DX9 pueda ser portada o usada sin tener que reprogramar las partes gráficas en OpenGL o Vulkan para poder ser usadas en linux u otros SO (siempre habría que reprogramar todo lo que tenga que ver con el SO, claro, por eso se usa desde wine, porque es más rápido y eficiente usar nativamente DX9 que una capa que traduzca cada llamada a una función DX9 por una o más funciones OpenGL que hagan el trabajo equivalente).

    DX10 o más aún no tienen un equivalente a Gallium Nine.

    El rollo opengl, vulkan... no sé a qué te refieres. OpenGL es una api gráfica de semialto nivel (en su origen era de alto nivel, a partir de la llegada de los shaders cada vez se han ido introduciendo más y más elementos para poder usarla a bajo; al ser de alto nivel, hay muchas funciones muy complejas que tienen que ser añadidas vía drivers, lo que los hace muy pesados y complejos y gordunflos), Vulkan es una API gráfica de bajo nivel (en la que todo el trabajo gordo y sucio lo hacen los programadores de aplicaciones -o más bien los de frameworks que se usan para desarrollar aplicaciones y facilitarle la vida a los programadores-, así que los drivers son más sencillos y eficientes, aparte de que su diseño es más moderno y está adaptado a la época actual: paralelismo, virtualización, acceso y uso de múltiples y distintos recursos gráficos de hardware instalados directamente desde la aplicación y no desde drivers, etc).

    CrossOver/CodeWeaver son marcas que explotan Wine comercialmente. Desarrollan wine, lo parchean para las aplicaciones específicas que se les demandan y ofrecen soluciones más profesionales y con soporte. O sea, básicamente son wine enfocados al entorno empresarial (donde no quieres que una actualización te rompa una aplicación que en la anterior te funcionaba).

    Todo eso rinde... pues depende xD

    Espero haberte aclarado el jaleo un poco.
  1. #9 No hay duplicación de esfuerzos en el sentido de que darán soporte y apoyarán a los drivers libres. Los privativos son para entornos corporativos (y estos pagan por dicho soporte, no es tanto "esfuerzo" o al menos se compensa).
  1. #5 En AMD soportan a grandes empresas y corporaciones. De ahí unos drivers cerrados y que cumplen ciertos requisitos de estabilidad y funcionamiento. El rendimiento no es exactamente lo que buscan. Y aparte, apoyan los drivers libres (AMD trabaja activamente con la comunidad en su desarrollo), con lo cual no es un "oh, sorpesa, el rendimiento EN JUEGOS es mayor con el driver libre", es un trabajo bien hecho y que beneficia a ambos drivers (dado que los cerrados comparten actualmente el espacio en el kernel y parte de infraestructura con los abiertos).

    El caso de vulkan es parecido, usan los módulos de kernel que comparten con los drivers libres y ha sido creado para dar soporte a empresas y entornos con otros requisitos, pero apoyan al driver libre. La idea era liberar su driver privativo de vulkan antes, pero los lanzamientos de hardware y la cantidad y capacidad de la mano de obra es limitada (no sólo es liberar esto, están trabajando muy duro para incorporar al kernel ciertas partes clave de sus drivers para dar soporte a cosas como freesync, aún les queda mucho trabajo para incorporar ciertos componentes necesarios para el soporte de su pila de computación heterogenea y openCL, etc), así que se ha ido posponiendo.

    Yo antes que decir que lo han hecho porque los drivers libres le hayan comido la tostada (en JUEGOS) diría que lo han hecho aprovechando el lanzamiento de su nueva generación de drivers en windows, por tener cosas que anunciar en la plataforma de linux.

35 años del "Thriller" de Michael Jackson [74]

  1. #71 Ya lo puse yo en el otro comentario. El que habías puesto tú era un montaje sobre Thriller con la película, pero aunque los paralelismos puedan ser evidentes, pierde mucho por no tener el audio original de la película.
  1. #57 Claro, por eso la gente cogía canciones de Bob Dylan y sacaba mejores versiones que las del propio artista... (y no una, ni dos, sino muchas de sus canciones).
« anterior1

menéame