Algo viejo, algo prestado, algo nuevo y algo azul

Cada día vertemos más confianza en un campo relativamente nuevo como es la seguridad informática. Muestra de ello son las contraseñas, un concepto más bien primitivo (si bien el uso informático está relativamente cercano en el tiempo, las contraseñas indudablemente llevan milenios en uso. Particularmente entrañable revisar la historia de su primo el shibboleth) del que pende muchísima de nuestra seguridad.

De momento no existen muchas alternativas a las contraseñas que sean viables para la mayoría de usos comunes que les damos. Una manera de complementar la seguridad de las contraseñas es aplicar el concepto de un doble factor de autenticación. Un factor de autenticación es algo que usamos para identificarnos. Normalmente se clasifican de la siguiente manera:

  • Algo que sabemos (por ejemplo, una contraseña)
  • Algo que tenemos (por ejemplo, un dispositivo físico específico)
  • Algo que somos (por ejemplo, nuestra huella dactilar)
  • Un lugar en el que estamos (por ejemplo, nuestra casa)

Combinando dos factores podemos protegernos del fallo de uno de ellos. Un uso típico es tener un dispositivo físico que genera códigos numéricos cada cierto tiempo y tener que introducir nuestra contraseña y este código para identificarnos. Si alguien descubre nuestra contraseña, no podrá hacerse pasar por nosotros porque no tendrá el dispositivo físico; al contrario, si alguien nos roba el dispositivo físico, normalmente no conocerá nuestra contraseña.

Obviamente esto no ofrece una protección total (alguien puede robarnos y torturarnos para que le digamos la contraseña), pero sí nos protege de unos cuántos ataques verosímiles.

Muchos sistemas que requieren identificación, como nuestra cuenta de correo, nuestro banco o incluso las redes sociales nos permiten utilizar dobles factores para identificarnos y proteger nuestra identidad. Además, aparte de dispositivos físicos dedicados a actuar como doble factor, se han estandarizado protocolos que permiten que podamos usar nuestros móviles como un factor.

Se nos anima mucho a utilizar estos dobles factores para protegernos, pero cabe ser cauteloso.

Un primer elemento que tenemos que considerar es el uso de envío de mensajes SMS a nuestro móvil como factor de autenticación. Se han documentado suficientes casos de duplicación de SIM, en los que mediante ingeniería social alguien consigue un duplicado de la SIM de nuestro móvil con lo que puede recibir los SMS y saltarse el doble factor, como para que varias entidades hayan dejado de recomendar los SMS como factor de autenticación.

Otro elemento, más peliagudo, es que tenemos que analizar el riesgo que supone perder (sin actor malicioso de por medio) nuestro segundo factor de autenticación. Al igual que perder una contraseña puede ser más problemático de lo que parece (por ejemplo, si perdemos la contraseña para acceder a nuestro correo- de manera que no podemos pedir un enlace para cambiar nuestra contraseña por correo), hay que tener claro cómo recuperar una cuenta en la que dependemos de un segundo factor como autenticación.

Para usos laborales, las empresas pueden establecer protocolos relativamente sencillos para identificarnos que aprovechen el hecho de que nuestros compañeros de trabajo nos conocen, por ejemplo. En general, el uso de doble factor laboralmente es por tanto fácil, de coste razonable y efectivo.

Pero para usos personales, la cosa se complica. Podríamos pensar que hay factores de autenticación que no podemos perder, como los que “somos”- nuestra huella dactilar, el iris, etc. A pesar de que el uso de este tipo de identificadores es conveniente (soy el primero que desbloquea su móvil con su huella), tenemos que considerar que el otro nombre de esta práctica (a parte de “identificación biométrica”) es “la contraseña que no puedes cambiar y que todo el mundo puede ver”. Se ha engañado a lectores de huella creando reproducciones de huellas dactilares a partir de fotografías. Cualquier pérdida de seguridad de un identificador biométrico es definitivo.

Un dispositivo físico así mismo puede perderse. Afortunadamente, la mayoría de sistemas de doble autenticación permiten tener varios dobles factores que podemos usar alternativamente. Por ejemplo, es típico poder crear un conjunto de códigos de un solo uso que podemos imprimir, por ejemplo, y utilizar en caso de perder el móvil. Sin embargo, dependiendo de lo crítico que sea una cuenta, la urgencia con la que podamos necesitarla, etc. podemos comenzar a plantearnos preguntas como “qué pasa si necesito un factor alternativo y estoy lejos de mi casa donde guardo mi copia impresa de mi doble factor de respaldo” o “qué pasa si se incendia mi casa y se destruye”, por no hablar de que somos seres humanos y cometemos errores.

Yo, personalmente, de momento no utilizo doble factor- lo que conlleva un déficit de seguridad importante, pero que personalmente creo que me vale la pena y puedo compensar con otros mecanismos (uso de un gestor de contraseñas, las medidas adicionales de Google que protegen mi cuenta de correo, etc.). Existen medidas en este sentido (como contactos en los que confiamos de emergencia) y probablemente existe espacio para más mejoras en este sentido.

Es recomendable analizar la situación de cada uno y decidir- creo que el uso de doble factor en entornos personales tiene sentido bajo muchos puntos de vista, pero sólo cada uno puede juzgar los riesgos y ventajas de cada sistema.

La iglesia catódica

¿Acertaron de pleno los creadores de YouTube con su nombre? ¿Los “smart” phones nos han enganchado a la nueva caja tonta?

Vivo un poco ajeno al mundo de las imágenes en acción para responder adecuadamente a esa preguntas (aunque todo apunta a que sí), pero me es conveniente documentar dos proyectos relacionados con YouTube que, sorprendentemente en estos días, no son youtube-dl.

Uno es NewPipe. NewPipe es una aplicación Android open source (es decir, sus entrañas están al alcance de todos) que permite ver vídeos de YouTube, como la propia aplicación de YouTube. Para ello, imita a un navegador web visitando YouTube sin hacer login. Curiosamente, se salta los pasos de mostrar anuncios y dificulta bastante que YouTube nos identifique fácilmente. Adicionalmente, implementa funcionalidades en la propia aplicación, como la suscripción a canales, con un mecanismo propio que, aunque cuenta con desventajas (no nos “sigue” de dispositivo a dispositivo), nos permite hacer cosas que no se pueden hacer usando YouTube sin hacer login. También cuenta con funcionalidades como poder reproducir el sonido de los vídeos sin tener la aplicación en primer plano, o descargar vídeos.

¿Tiene pegas? Para empezar, una aplicación así va en contra de los términos de uso de la Play Store de Google, así que no la podremos encontrar ahí. Recomiendo el uso de F-Droid para instalarla. F-Droid es una tienda de aplicaciones Android alternativa que ofrece sólo aplicaciones open source como NewPipe. Esto está contemplado dentro de Android- podemos configurar Android fácilmente para que nos permita instalar aplicaciones de fuera de la Play Store, instalar F-Droid y con F-Droid instalar nuevas aplicaciones.

¿Es esto legal? Pues dependerá de la legislación que rija sobre cada uno. ¿Es peligroso? Un riesgo podría venir por instalar una aplicación que no está aprobada por Google, que supuestamente evita que se publiquen aplicaciones con funcionalidades maliciosas ocultas. Sin embargo, dado que NewPipe es una aplicación open source, en teoría cualquiera podría auditar sus entrañas, verificar que no hay tales funcionalidades ocultas y verificar que la descarga que ofrece F-Droid se corresponde con el código fuente.

Así mismo, podría existir el riesgo de que Google “castigue” a los usuarios de NewPipe, por ejemplo, cerrando sus cuentas Google, algo que no es poca broma. Sin embargo, aparte de que no constan casos, a falta de alguna puerta trasera en Android, dado que NewPipe interactúa con YouTube sin hacer login, no debería haber manera fiable de identificar quién usa NewPipe. Así mismo, no ha habido manifestación alguna de Google en contra de NewPipe- más allá de que los términos de la Play Store evitan que, como muchas otras aplicaciones, la podamos encontrar allí.

Un proyecto similar a NewPipe es Invidious, una web alternativa que nos ofrece el contenido de YouTube que forma parte de la ilustre familia compuesta por Nitter (Twitter) y Bibliogram (Instagram). Estas webs reimplementan la funcionalidad de webs con contenido público como YouTube, permitiéndonos acceder a él como un intermediario que protege nuestra identidad. Al igual que NewPipe, Invidious curiosamente se olvida de mostrarnos anuncios y dificulta el seguimiento por parte de Google de nuestras acciones.

Al ser una aplicación web, Invidious debe ser hospedada por alguien. Al ser open source, cualquiera puede crear su propia instancia. A diferencia de NewPipe, que siendo una aplicación nos la bajamos y la ejecutamos en nuestro móvil, Invidious se ejecuta en un servidor al que accedemos. Hay un listado de instancias en la propia web de Invidious.

Sin embargo, dado que es una aplicación web, si bien el código fuente de Invidious es open source al igual que NewPipe, en este caso al ser una aplicación web, no podemos validar que la instancia a la que nos conectamos de Invidious se corresponda con el código fuente que alguien podría haber auditado y verificado que no contiene funcionalidades maliciosas. Sólo creando nuestra propia instancia de Invidious podremos tener esta certeza. Además, la instancia que usemos puede dejar de funcionar, aunque en este caso podriamos cambiar y seguir usando otra instancia.

Por lo demás, el análisis es bastante similar al de NewPipe- con las diferencias lógicas derivadas de que una es una aplicación para móvil y la otra una aplicación web.

Bola extra: aquí un artículo sobre un soporte histórico, desconocido para mí, de películas que al parecer tuvo su momento en los ochenta.

Sagrada correspondencia

Hace unos días salió una noticia sobre alguien que había perdido el acceso a su cuenta de Google. Esto me ha llevado a revisar un poco mi situación.

Adelanto que hay un factor que aún no tengo resuelto, que es que uso mi cuenta de Google para identificarme en servicios no Google. Dentro de la configuración de vuestra cuenta de Google podéis ver en qué webs podéis entrar usando vuestra cuenta de Google. En mi caso son 17, y podría perder esas cuentas si perdiese mi cuenta Google. Algunas de ellas permiten mecanismos alternativos de identificación, así que vale la pena auditar aquellos servicios que sean importantes.

Otro punto es el correo. La inmensa mayoría de servicios usan una dirección de correo para identificarnos y funcionalidades como “olvidé mi contraseña” son especialmente peligrosas si perdemos el acceso a la dirección de correo asociada.

Personalmente, no uso prácticamente jamás ninguna dirección del dominio gmail.com. Tengo un dominio propio y uso un dominio de un allegado cercano, y uso direcciones de correo de esos dominios, que es bastante complicado perder (notifican con mucho margen para renovar, es un servicio de pago y no he oído nunca que se rescinda un dominio unilateralmente). Esa es la dirección de correo; la cuenta de correo en sí si la tengo con Google, que almacena el correo y me da acceso a él (nota: uso una arcaica versión gratuita de Google Workspaces. Para asuntos personales, no recomiendo usar Google Workspaces. Es posible usar un dominio propio con Google sin Google Workspaces). Pero al usar un dominio propio, puedo reemplazar a Google sin demasiado problema si fuera necesario- sin tener que cambiar mi dirección de correo.

Con esto, mi correo lo almacena Google, que también perdería si no pudiese acceder a mi cuenta. Google proporciona una amplia variedad de maneras de exportar el correo. Para empezar, he decidido usar un procedimiento bastante sencillo e incómodo, pero efectivo.

Uso isync, una herramienta para sincronizar cuentas de correo IMAP con archivos locales. IMAP es un protocolo para consultar el correo muy común en herramientas como Thunderbird y Outlook. Google da acceso al correo de GMail mediante IMAP, con lo que podemos usar cualquier herramienta IMAP como isync.

Para hacer la sincronización, basta crear un sencillo archivo de configuración:

IMAPAccount gmail
Host imap.gmail.com
User <usuario_de_gmail>
PassCmd +"head -1"
SSLType IMAPS

IMAPStore gmail-remote
Account gmail

MaildirStore gmail-local
SubFolders Verbatim
Path ~/.mail/gmail/
Inbox ~/.mail/gmail/Inbox

Channel gmail
Master :gmail-remote:
Slave :gmail-local:
Patterns *
Create Both
SyncState *

El fragmento +"head -1" hace que isync nos pregunte nuestra contraseña por pantalla (de una manera bastante fea, y mostrando la contraseña por pantalla) al hacer la sincronización. Ejecutando mbsync -a, tendremos que teclear nuestra contraseña interactivamente y se realizará la sincronización.

Para que esto funcione, sin embargo, necesitaremos permitir el acceso “menos seguro” a nuestra cuenta Google, que permite el acceso al correo IMAP mediante una simple contraseña (mecanismo que Google no considera seguro). De momento y para salir del paso, dado que tampoco me preocupo de ejecutar el proceso automáticamente, lo que he hecho es programarme un recordatorio para ejecutar el proceso semanalmente y sólo activar el acceso “menos seguro” mientras se ejecuta el proceso.

El brazo rápido de la manzana

Aviso: no me considero un experto mucho menos en temas de arquitectura, historia de la computación, la supercomputación o incluso el mercado informático. Tampoco he hecho un esfuerzo brutal en verificar todo lo que digo debajo. Comentarios, correcciones y sugerencias más que bienvenidas.

Me agrada contemplar como de un tiempo a esta parte, la dictadura de la arquitectura x86 pierde poco a poco su hegemonía.

Tras haber trasteado levemente con los procesadores MOS Technology 6502 y miembros de la familia m68k, casi todos los detalles a bajo nivel de la arquitectura de los PC compatibles siempre me han parecido un tanto… carentes de estética. Mi único encontronazo programando directamente un procesador x86 fue hace más de dos décadas y también me dejo un mal sabor de boca.

Por tanto, siempre me ha quedado pendiente que algún día alguien derroque el status quo de los PC compatibles. La adopción de EFI siempre me pareció un paso adelante, aunque el impacto real en el usuario final es muy pequeño.

Ya antes del iPhone (pero antes de que nadie predijese la revolución que se cocía), muchos móviles ya llevaban pequeños procesadores ARM, ya que Intel tardó mucho en mostrar interés en poner sus procesadores en dispositivos más pequeños que los portátiles PC compatibles, con lo que ni siquiera era viable intentar ponerle un x86 a un móvil por temas de consumo. Los pequeños y eficientes procesadores ARM eran la decisión natural para estos dispositivos. No sé en qué momento preciso los dispositivos ARM en manos de usuarios superaron al número de dispositivos x86, pero seguramente inconscientemente servidor esbozó una pequeña sonrisa en su rostro. Paradójicamente, seguramente más o menos en el mismo momento, también vencieron las plataformas de hardware cerradas a las (relativamente) abiertas

Los x86, sin embargo, aún cuentan (¿o contaban? Ahora nos ocupamos de eso) con la ventaja del “rendimiento de hilo único”. La masiva inversión en exprimir al máximo el rendimiento de los procesadores x86 tradicionalmente ha querido decir que son los procesadores que pueden dar más rendimiento ejecutando tareas generales no paralelizables (creo que aplicando la restricción “a un coste razonable”).

Muchas tareas son paralelizables; es decir, podemos poner más procesadores a ejecutarlas. Cuando tenemos esta posibilidad, el beneficio de multiplicar el número de procesadores adquiere mucha más importancia que hacer que un procesador individual sea más rápido. Esto lo podemos ver reflejado en sitios como los listados de los supercomputadores más potentes del mundo, donde x86 no siempre ha dominado tan claramente.

Más recientemente, también hemos visto trabajo interesante en el área de “las tareas generales”. Hay ahí un estudio interesante sobre los procesadores muy especializados; allí donde por ejemplo el Commodore Amiga hacía cosas mágicas gracias a sus procesadores gráficos, pero allí donde también murió un poco en el boom de los juegos con gráficos tridimensionales… y allí donde poco más tarde comenzaron a coger carrerilla los procesadores pensados para acelerar el rendimiento de los gráficos tridimensionales que han dado pie a otra revolución informática. Estos procesadores altamente especializados no son nada adecuados para realizar “tareas generales”, pero han encontrado usos más allá de los gráficos tridimensionales en áreas como el aprendizaje computacional. Precisamente la “simplicidad” de estos procesadores facilita su aceleración y paralelización hasta límites insospechados (la tarjeta gráfica de mi ordenador para videojuegos tiene casi 2000 unidades de ejecución comparadas con las decenas que a lo sumo tienen los procesadores x86 convencionales) y hacen que, por un precio razonable, puedan dar un rendimiento a años luz de lo que puede dar un x86 (o cualquier otro procesador de propósito general).

Pero aun así, hasta estos días, era complicado comprarse un portátil que no llevase un procesador x86, y los sistemas de escritorio como las populares Raspberry Pi (basadas en ARM, como los móviles) ofrecían un rendimiento bastante pobre. Apple mismo era el último reducto de los ordenadores personales de uso general no basados en los procesadores x86, pero hasta ellos tuvieron que abandonar ese barco en 2006, pues sus ordenadores basados en PowerPC eran simplemente lentos comparados con sus competidores.

Se ha invertido mucho dinero desde entonces gracias a los móviles en los procesadores ARM. Apple diseña sus propios procesadores ARM, que arrojan unas cifras que suenan muy bien de rendimiento cuando se miden. Personalmente siempre me tomo los números que saca Apple con bastante escepticismo- precisamente en su época PowerPC todas sus presentaciones sacaban unos números magníficos, que se desvanecieron justamente en ese fatídico 2006. Además, la cerrazón de los entornos iOS e iPadOS siempre me han hecho desconfiar mucho de estas mediciones (por no hablar ahora, que lo haremos más adelante, de lo endiabladamente complicado que es medir el rendimiento de un procesador objetivamente).

Tan buenas son estas cifras, que Apple ha decidido volver a apostar por procesadores no x86 en sus portátiles y sistemas de escritorio, y los acompaña de otras cifras y declaraciones que creo que interesa analizar detenidamente.

Voy a discutir explícitamente lo que captura el Internet Archive a día de hoy en la página de Apple sobre sus procesadores M1.

System-on-a-Chip (SOC)

Lo primero que dice es que el M1 es un SOC, como todos los ARM. Los ordenadores x86 que conocemos todos en general vienen con un procesador separado, acoplado o soldado a una placa base en la que hay más componentes, como por ejemplo, la memoria. Creo que no hay procesadores ARM en ese formato- todos vienen en un chip único con memoria y otros componentes integrados. Esto suele tener interesantes beneficios de eficiencia, rendimiento, portabilidad y coste, pero por otra parte descarta completamente cosas que aún podemos hacer en muchos PCs como aumentar la memoria o cambiar una tarjeta gráfica.

Ciertamente esto ya no es posible en muchos portátiles x86, e incluso en algunos sistemas que no son de escritorio, pero es algo que perdemos casi completamente adoptando un SOC, aunque inventos como Thunderbolt podrían permitirnos usar tarjetas gráficas Thunderbolt para complementar un SOC. También podría ser posible adoptar una arquitectura que permita acoplar más procesadores (los sistemas Blade hacen algo similar). Además, como hemos comentado, para muchas tareas podemos tirar directamente por apilar más ordenadores en vez de ampliar un sólo sistema- véase lo que se divierte la gente fabricando minisuperordenadores aglutinando varias Raspberry Pi.

Memoria unificada

Después de esto Apple recaba en que integrar la memoria en un SOC tiene ventajas de rendimiento y nos proporciona las primeras cifras de rendimiento (me da igual cuántos transistores tiene un procesador- de hecho Apple lo vende como que más transistores mejor y no creo que eso sea inequívocamente cierto) y las primeras notas al pie.

Up to 3.9X faster video processing
Testing conducted by Apple in October 2020 using preproduction MacBook Air systems with Apple M1 chip and 8-core GPU, as well as production 1.2GHz quad-core Intel Core i7-based MacBook Air systems, all configured with 16GB RAM and 2TB SSD. Tested with prerelease Final Cut Pro 10.5 using a 55-second clip with 4K Apple ProRes RAW media, at 4096×2160 resolution and 59.94 frames per second, transcoded to Apple ProRes 422. Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Air.

Apple cuidadosamente especifica la GPU del M1 y sus 8 cores que da como casi 4 veces más rápida que la CPU de su Air anterior de 4 cores. La mitad de ese 4x ya puede ser que básicamente estamos doblando el número de unidades de ejecución en un proceso que seguramente es paralelizable. Además, como hemos comentado, una GPU especializada puede tener ventajas en tareas específicas sobre una CPU de propósito general. Quizá sería interesante saber cómo se podría optimizar este proceso en, pongamos, una GPU Nvidia. Seguramente la arquitectura de memoria en el SOC da ventajas en esta prueba, pero me sorprende que Apple use esta prueba para hablar de ello. Por último, cabe señalar que el sistema en cuestión es un Air, un portátil ultradelgado. Es conocido que la debilidad de los x86 son estos sistemas donde no pueden alcanzar su máximo rendimiento. Por supuesto es harto interesante que en un portátil ARM nos dé mejores prestaciones, pero habría que ver la comparativa con un sistema de escritorio para tener una perspectiva completa.

Up to7.1X faster image processing
Testing conducted by Apple in October 2020 using preproduction Mac mini systems with Apple M1 chip, and production 3.6GHz quad-core Intel Core i3-based Mac mini systems, all configured with 16GB of RAM and 2TB SSD. Prerelease Adobe Lightroom 4.1 tested using a 28MB image. Performance tests are conducted using specific computer systems and reflect the approximate performance of Mac mini

Similar al punto anterior, pero aquí sí comparan con un sistema de escritorio, pero un Mac mini y no precisamente con el x86 más potente del mundo (el i3 es el modelo bajo de gama).

Rendimiento de CPU

Up to 3.5X faster CPU performance
Testing conducted by Apple in October 2020 using preproduction MacBook Air systems with Apple M1 chip and 8-core GPU, as well as production 1.2GHz quad-core Intel Core i7-based MacBook Air systems, all configured with 16GB RAM and 2TB SSD. Tested with prerelease Final Cut Pro 10.5 using a 55-second clip with 4K Apple ProRes RAW media, at 4096×2160 resolution and 59.94 frames per second, transcoded to Apple ProRes 422. Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Air

Se refieren aquí a la misma nota al pie que en su reclamo de “Up to 3.9X faster video processing” de más arriba, con lo que aplican las mismas observaciones, además de que es un poco raro que usen la comparativa de GPU contra CPU para hablar de 3.5x el rendimiento de CPU (contra la mejora de 3.9x anterior).

Our high‑performance core is the world’s fastest CPU core when it comes to low‑power silicon. And because M1 has four of them, multithreaded workloads take a huge leap in performance as well.
Testing conducted by Apple in October 2020 using preproduction 13‑inch MacBook Pro systems with Apple M1 chip and 16GB of RAM measuring peak single-thread performance of workloads taken from select industry-standard benchmarks, commercial applications, and open source applications. Comparison made against the highest-performing CPUs for notebooks commercially available at the time of testing. Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Pro

Creo que se refieren aquí a que tienen el mejor rendimiento en tareas generales no paralelizables en procesadores de bajo consumo. Puede ser cierto sin demasiados matices (ya hemos comentado que los procesadores x86 no alcanzan su mejor rendimiento en portátiles), aunque vuelve a ser cierto aquí que medir rendimiento de procesadores objetivamente es complicado y que están excluyendo sistemas de escritorio.

En este punto también hablan de sus unidades de ejecución “eficientes”. Esta es una idea harto interesante en la que se ha trabajado en móviles recientemente, que consiste en tener unidades de ejecución de diferente potencia para mejorar el uso de batería. Esto sí es un hito en portátiles y que seguramente contribuye a mejorar la vida de batería significativamente.

Eficiencia

Up to 2X faster CPU performance
Matches peak PC performance using 25% of the power
At just 10 watts (the thermal envelope of a MacBook Air), M1 delivers up to 2x the CPU performance of the PC chip. And M1 can match the peak performance of the PC chip while using just a quarter of the power.
Testing conducted by Apple in October 2020 using preproduction 13‑inch MacBook Pro systems with Apple M1 chip and 16GB of RAM. Multithreaded performance measured using select industry‑standard benchmarks. Comparison made against latest‑generation high‑performance notebooks commercially available at the time of testing. Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Pro.

Aquí se refiere a rendimiento paralelizable y hábilmente no especifica absolutamente nada de contra qué compara. Muy difícil de evaluar, pero podrían estar comparando contra sistemas con menos cores o con mala gestión térmica. A saber. Que los procesadores ARM rinden mejor a bajo voltaje no está bajo mucha discusión (los procesadores x86 de bajo voltaje son notablemente lentos).

Rendimiento gráfico

Pequeño apunte que a esto sigue una gráfica que habla que han triplicado el rendimiento por vatio, pero es una gráfica muy extraña. Pero me parece algo bastante creíble a pesar de la gráfica.

Siguen hablando del rendimiento gráfico. Esto también es bastante creíble; los procesadores x86 a veces integran GPUs que están bien, pero que no son para tirar cohetes precisamente, sobre todo comparando con las GPUs dedicadas de NVIDIA, de las que hay versiones para portátiles con rendimiento limitado y probablemente mucho peor consumo que la GPU integrada del M1. Así pues es una mejora interesante si queremos hacer algo de gráficos con buen consumo de batería, y desde luego seguramente veamos una mejora muy significativa contra un x86 sin procesadores gráficos dedicados.

Rendimiento especializado

Luego nos apuntan mejoras en cosas como aprendizaje computacional. Lo mismo que con el rendimiento gráfico; seguramente machaca a las gráficas integradas de los procesadores x86, pero no creo que se acerque a GPUs NVIDIA (salvo si lo miramos en consumo, claro). Hablan de una mejora de 16x respecto a x86, cuando según tengo entendido NVIDIA está muchísimo más lejos.

Consumo de batería

Aquí, a diferencia de en otras secciones, es Apple quien tiene el histórico de dar las cifras más creíbles de batería (y los fabricantes de PCs no Apple tienen el histórico de mentir como bellacos). Parece ser que hay portátiles x86 que presumen de cifras similares a las que apunta Apple, pero apostaría a que Apple vuelve a tomar la delantera que había perdido en cuanto a duración de batería gracias a la eficiencia ARM.

Conclusiones

Estoy bastante convencido que en portátiles, los nuevos sistemas de Apple basados en ARM seguramente sean equivalentes o superiores a los portátiles más delgados basados en x86. Aquí me repatea un poco la obsesión con la delgadez de los portátiles (que no sólo afecta a Apple), que redunda no sólo en peor rendimiento, sino también en peores teclados, menor facilidad para reparar e incluso ampliar, peores baterías y un sinfín de cosas que sacrificamos en aras de una delgadez que no aporta demasiado. Seguramente los portátiles con GPUs NVIDIA mantengan grandes ventajas en determinadas áreas, sacrificando batería (también habría que intentar valorar la paradoja de que a veces los procesadores más rápidos pueden ser más eficientes por el hecho de que necesitan menos tiempo a pleno rendimiento para completar las tareas que queremos).

Es decir, que es posible que de nuevo Apple haya sacado un portátil que me gusta en algunos sentidos como los primeros Air baratos que durante bastante tiempo no tuvieron rival. Como aquel, seguro que no será el mejor portátil para todo el mundo, pero sí para muchos (al menos los que toleren vivir en macOS… y viendo como se adapta el mundo a un portátil no x86- parece que de momento hay bastantes baches, aunque espero que se resuelvan bastante rápido). En escritorio y de potencia máxima sin calificativos, lo veo poco probable.

Es digno de admirar, por otra parte, las continuas apuestas en las que Apple arriesga. Aunque algunas de ellas (pantallas táctiles, delgadez, sistemas cerrados) han resultado nefastas, al menos para mí, muchas de ellas han arrastrado al resto de la industria a mejoras de las que nos beneficiamos todos.

Y quién sabe, quizá algún día acabemos de enterrar a los feos x86.

Si los fanfarrones volasen

Hace casi 20 años que salió Google Earth, esa maravillosa recreación del globo terráqueo que podíamos disfrutar desde nuestros hogares y en la que muchísimos perdimos una significante cantidad de tiempo mirando una versión tridimensional limitada de lugares. Curiosamente, quizá viendo muchos más lugares que conocíamos que no descubriendo nuevos paisajes.

Dos décadas más tarde, después de desembolsar 70 eurazos en Steam por el Microsoft Flight Simulator (un verdadero derroche, considerando el Game Pass de Xbox) y comprobar que quizá mi GeForce GTX 1050 Ti en mi PC de 2017, en streaming por Internet, no daba… desembolsé mil eurazos más por un PC nuevo con una ya ligeramente desfasada GeForce GTX 2060, en una perfecta demostración de irracionalidad supina.

Pero qué bonito es contemplar lugares comunes desde el aire gracias a un derroche de esfuerzo inimaginable por un conjunto de fanfarrones que querían intentar demostrar que su tecnología era mejor que la tecnología de Google.

Dicen los de Microsoft que su recreación del globo terráqueo es, básicamente, 2 petabytes de datos. No tengo ni idea de si Google Earth es más o menos que esto. Son mundos muy distintos. En zonas urbanas importantes, Google Earth tiene datos tipo Street View para recrear edificios con cierto detalle, cuando en Flight Simulator, pocos edificios y estructuras están recreados tridimensionalmente a partir de imagen real. Flight Simulator mayormente trabaja con la visión aérea del mapa e infiere edificios, árboles, carreteras y unas cuántas estructuras más a partir de la imagen a vista de pájaro. El resultado es que los modelos tridimensionales de Earth son mucho más fidedignos, pero también que Flight Simulator pinta una aproximación tridimensional de la realidad en todo el globo, cuando en muchos casos Google Earth sólo da la visión mayormente plana del mundo.

Flight Simulator intenta dar un mundo que parece real, pero impreciso; los ríos parece que llevan agua, las carreteras tienen coches que se mueven por ellas y el mundo está iluminado de noche de una manera que cualquiera que haya volado de noche podrá identificar. En muchas ocasiones no es preciso, pero se acerca bastante a reflejar lo que veríamos desde un avión sobrevolando un planeta Tierra recreada a veces con realismo y a veces con un poco de cubismo.

Es imperfecto, desde luego, y hay recreaciones mucho más precisas en otros videojuegos, pero ninguna con la ambición de recrear todo el planeta. Vuele uno por dónde vuele, rara vez da la sensación de haber llegado a un límite que los desarrolladores han ignorado, si bien se nota los lugares en los que se ha puesto esfuerzo humano en vez de uno meramente automático.

Este intento de digitalizar la realidad no se queda ahí; el mundo de Flight Simulator recrea el clima y el tráfico aéreo del mundo, aparentemente los aviones del mundo real se ven reflejados dentro del juego, y ya hay muchos que se dedican a ver huracanes, tornados y tormentas desde el confort de sus casas (aunque también le podemos pedir al juego el clima que deseemos, para aquellos que rara vez vemos la nieve en nuestras casas). Por no olvidar que sí, el Flight Simulator es un simulador de vuelo que podemos ajustar desde una experiencia que permita a un lego sobrevolar su casa fácilmente hasta algo que dicen sirve de entrenamiento para una licencia de piloto comercial.

De hecho, hay que decir que si el propósito del juego fuera realmente una simulación del vuelo comercial o incluso recreativo, mucha de la fantástica recreación del mundo dentro del juego es meramente ornamental e incluso inútil- volando como se volaría en la realidad jamás veríamos gran parte del esfuerzo- o lo veríamos por un breve instante antes de estrellarnos o ser detenidos por sobrevolar zonas habitadas a ras de suelo. Si esto es un juego, un desafío a los desarrolladores de Google Earth, un intento de vender tarjetas gráficas o una manera de ilusionarlos con lo que será posible en un par de décadas, es difícil de decir; quizá todas las anteriores sean ciertas en mayor o menos medida.

¿Vale la pena el Flight Simulator? Es una pregunta compleja, ya que aparte del coste del juego (mínimo si a uno no le importa tener una licencia perpetua y decide tirar de Game Pass) se le puede sumar el hierro necesario para mover esta maquinaria. Podéis buscar en Youtube vídeos para configuraciones de PC aproximadas de tarjeta, procesador y memoria que os den una idea del nivel gráfico/coste que podéis disfrutar. Así mismo, cabe valorar los diferentes niveles a los que podemos jugar- seguro que es una compra indispensable para aquellos que quieran un auténtico simulador de vuelo que recree la experiencia de pilotar. Los que quieran realizar turismo virtual también harían bien de probar antes Google Earth, que en ciertos aspectos supera la recreación de Microsoft, aunque en muchos se queda cortísimo.

Yo personalmente, me quedo con la relajante experiencia de poder sobrevolar cualquier punto del mundo, de día o de noche con una libertad imposible en el mundo real y sin estrés.

Trienio lingüístico

Veo que hace tiempo de la última vez que hablé sobre lenguajes de programación. Unas notas desde entonces:

Aunque el TIOBE (hablo del TIOBE porque es popular. Ningún índice es perfecto. Puede que el TIOBE sea el peor de todos, pero da un poco igual) no ha variado mucho en este tiempo, hay unas cuantas cosillas de las que podemos hablar.

Objective C ha caído desde el #5 hasta el #18, y su sucesor Swift está en el #16. Curioso. Swift parece un lenguaje harto interesante, pero como C#, me genera algo de desconfianza por estar ligado a un entorno muy concreto.

Go va subiendo. Es curioso que de los dos lenguajes impulsados por Google, el que me disgusta (Go y su terquedad en ignorar las últimas décadas de historia de la informática) se ha disparado y el que me gusta (Dart) no arranca ni a la de tres. Entiendo la popularidad de Go como lenguaje de tipado estático que permite generar binarios enlazados estáticamente con compilación cruzada amigable y además con recolector de basura; mientras Graal no coja impulso o Microsoft saque algo para .NET (que la última vez que miré no tenía nada usable) no tiene competencia en ese ámbito… Pero debería ser un nicho menos popular. Apuesto porque en muchos casos es el lenguaje para los que necesitan Java (tipado estático, recolector de basura y rendimiento) pero que están dispuestos a autoinfligirse dolor para no tener que usar Java.

Lamentablemente creo que la popularidad de Go va en detrimento de un lenguaje que me pirra como es Rust. Rust nos trae innovaciones académicas a un lenguaje sin recolector de basura que también hace binarios fácilmente desplegables. Una maravilla que debería ir comiéndole el terreno a C/C++, los dos lenguajes sin recolector de basura más populares- es mucho más fácil y agradable escribir Rust fiable donde uno antes escribiría C o C++. Lamentablemente ese no es mi ámbito habitual, con lo que tengo que buscarme excusas cada vez más raras para deleitarme con él. Porque no veo claro que Rust pueda comerle terreno a lenguajes con recolección de basura; sí, tiene cosas que muchos de ellos no tienen, pero también tiene el quebradero de cabeza de preocuparse de satisfacer al borrow checker. Yo no apostaría por Rust donde podría usar Java, por ejemplo.

Por último, Kotlin aún anda por el #33- algo pobre para el lenguaje de moda que Google también ha decidido impulsar como primer lenguaje para hacer aplicaciones sobre Android (offtopic: Fuchsia Programming Language Policy). Quizá que Swift se quede por el #16 quiere decir algo sobre Android e iOS. A mí me sigue pareciendo un bonito lenguaje alternativo a Java (aunque a parte de la JVM, también compila a JS/WASM y nativo mediante LLVM) que además quizá está motivando muchas de las mejoras que Oracle está metiendo (con gran acierto, en mi opinión) a marchas forzadas a Java últimamente. Pero yo sigo sin verlo reemplazando a Java fuera de Android (como Scala, Ceylon, etc.).

Como el trueno

Disculpen el meme:

r/Windows10 - "How likely are you to recommend Windows 10 to a friend or colleague?"
How likely are you to recommend Windows 10 to a friend of colleage?


I need you to understand that people don’t have conversations where they randomly recommend operating systems to one another

Parece indiscutible la evidencia sobre la efectividad del Net Promoter Score, pero sigue chirriándome un poco. Personalmente, en mi escala personal, raramente soy un promoter y puedo poner un 6 (detractor) a algo que no creo que necesite mejorar o que no puede mejorar eficientemente.

Pero bueno, igual hay peores maneras de, por ejemplo, formar un gobierno.

También me han recordado últimamente a Cynthia Rothrock, con:

, que aunque ahora viendo las respuestas al tuit, ya no puedo dejar de ver a su doble, me hizo gracia descubrir repasando su artículo en la Wikipedia, que triunfó antes en Asia antes de pasarse a la serie B directa a vídeo americana.

Finalmente, me pregunto si hay por ahí benchmarks de los nuevos Apple de escritorio con ARM. Las medidas de los chips de Apple para móvil siempre me han sorprendido un pelín y tengo bastante curiosidad por ver cómo se transladan a escritorio.