WEBVTT Kind: captions Language: es 00:00:00.000 --> 00:00:04.040 Bienvenidos a un nuevo episodio de Mixio, podcast diario de tecnología. Mi nombre es Alex Barredo 00:00:04.040 --> 00:00:09.000 y este episodio no está dentro de la programación habitual, pero tengo que deciros que va a 00:00:09.000 --> 00:00:14.040 ser el último de los programas diarios hasta la semana que viene, porque estamos teniendo 00:00:14.040 --> 00:00:20.280 una situación un poco complicada por aquí por casa, así que consideradlo como si estuviera 00:00:20.280 --> 00:00:24.840 de vacaciones. Y no me echéis mucho de menos, que solo van a ser unos pocos días, no os 00:00:24.840 --> 00:00:25.840 preocupéis. 00:00:25.840 --> 00:00:33.000 Comenzamos con las noticias de tecnología, porque lanzaron el viernes el SDK para Vision 00:00:33.000 --> 00:00:39.600 OS por parte de Apple, y además de poder empezar a desarrollar ya cositas para estas 00:00:39.600 --> 00:00:45.560 nuevas gafas o cascos de realidad virtual aumentada, mixta, extendida, como queráis 00:00:45.560 --> 00:00:52.560 decirlo, nos encontramos con el Reality Composer Pro, que básicamente es una forma de visualizar 00:00:52.560 --> 00:00:57.160 en los ordenadores Mac, mientras estás desarrollando las aplicaciones, cómo se van a ver cuando 00:00:57.160 --> 00:01:03.400 estén en las gafas, una especie de simulador. Para los que no sois desarrolladores, os interesa 00:01:03.400 --> 00:01:08.880 veros un vídeo que hay en las notas del episodio, porque dentro de este Reality Composer Pro 00:01:08.880 --> 00:01:15.200 podemos ver cómo va a ser el sistema operativo, al menos inicialmente, y cuáles van a ser 00:01:15.200 --> 00:01:22.880 muchas de las funciones de este nuevo estilo de interfaces que está desarrollando Apple. 00:01:22.880 --> 00:01:28.240 La verdad es que he visto ya bastantes desarrolladores haciendo algunas cosas chulas, pero espero 00:01:28.240 --> 00:01:33.300 que durante los próximos meses empecemos a ver cosas más interesantes, que no sean 00:01:33.300 --> 00:01:40.360 simplemente poner las mismas ventanas que tenemos en un Mac, en un iPad o en un iPhone 00:01:40.360 --> 00:01:47.800 directamente flotando en una especie de mundo virtualizado. Creo que eso tiene sentido, 00:01:47.800 --> 00:01:52.700 pero dentro de unos límites. Vamos a ver si los desarrolladores y Apple consiguen ir 00:01:52.700 --> 00:01:55.840 un paso más allá. 00:01:55.840 --> 00:01:59.080 Precisamente de sistemas operativos vamos con la siguiente noticia, y es que el gobierno 00:01:59.080 --> 00:02:06.360 alemán va a iniciar una investigación sobre Android Automotive OS, porque según su agencia 00:02:06.360 --> 00:02:14.140 reguladora de competición ve posibles o potenciales restricciones que serían anticompetitivas 00:02:14.140 --> 00:02:20.320 por parte de Google y de elementos que no permite hacer a los fabricantes de automóviles 00:02:20.320 --> 00:02:26.440 que optan por utilizar este sistema operativo de código abierto. La verdad es que lo veo 00:02:26.440 --> 00:02:31.760 muy complicado, pero creo que para que podáis comprender mejor esto, voy a volver a dar 00:02:31.760 --> 00:02:40.400 un poco de contexto sobre cómo funciona AAOS y cuáles son las dos capas que hay y si tiene 00:02:40.400 --> 00:02:43.760 sentido este rol que está haciendo Google. 00:02:43.760 --> 00:02:48.400 Lo primero es AAOS, que digamos es el sistema operativo de código abierto de la misma forma 00:02:48.400 --> 00:02:54.160 que existe un Android para smartphones y para tabletas de código abierto. Un kernel con 00:02:54.160 --> 00:02:59.400 unas aplicaciones por defecto, la gestión de los drivers, la gestión de las pantallas, 00:02:59.400 --> 00:03:05.040 las comunicaciones, etcétera. Y sobre ese sistema, pues cualquier persona o cualquier 00:03:05.040 --> 00:03:11.000 empresa puede decidir luego qué aplicaciones preinstala o sus propias tiendas, sus propias 00:03:11.000 --> 00:03:16.560 aplicaciones para controlar los aparatos multimedia, los mapas, las radios, etcétera. Es decir 00:03:16.560 --> 00:03:22.840 que la Mercedes o Volkswagen pueden coger eso. De hecho, lo están cogiendo y haciendo 00:03:22.840 --> 00:03:30.080 sus propias cosas. Que luego tú quieres como fabricante tener acceso a las aplicaciones 00:03:30.080 --> 00:03:35.760 por decirlo así de Google. Google ofrece una cosa que se llama el gas, que son los 00:03:35.760 --> 00:03:41.880 sistemas automovilísticos de Google. Y esto va en un único pack. Es decir, que o quieres 00:03:41.880 --> 00:03:48.280 todo o no quieres nada. Aquí están Google Maps, la tienda de aplicaciones, la integración 00:03:48.280 --> 00:03:53.180 con diversos servicios de Google. Esta segunda parte hay que pagarla, hay que licenciarse 00:03:53.180 --> 00:03:58.320 la Google y la otra es un sistema de código abierto que Google ofrece sin mayores problemas. 00:03:58.320 --> 00:04:06.080 Dice la entidad de competencia alemana que Google debería de permitir a los fabricantes 00:04:06.080 --> 00:04:11.360 poder elegir cuáles de las aplicaciones que están incluidas dentro del gas escoger. De 00:04:11.360 --> 00:04:16.920 la misma forma que puedan elegir únicamente Google Maps. No sé si esto tiene muchísimo 00:04:16.920 --> 00:04:23.080 sentido francamente, pero todo dependerá de que si a Google se le considera que tiene 00:04:23.080 --> 00:04:30.400 una posición dominante en este sentido y entonces entra en las nuevas categorizaciones 00:04:30.400 --> 00:04:37.120 de la DSA y la DMA de la Unión Europea. Pero bueno, francamente en esta posible guerra 00:04:37.120 --> 00:04:42.400 entre los fabricantes de automóviles y Google no me fío de nadie porque no creo que realmente 00:04:42.400 --> 00:04:49.720 nadie tenga las mejores intenciones para los consumidores finales y creo que los reguladores 00:04:49.720 --> 00:04:56.120 deberían de intentar entender este problema desde una perspectiva de mucho mayor largo 00:04:56.120 --> 00:05:00.760 plazo. Es decir, cuando te compras un smartphone lo vas a utilizar dos o tres años, cuando 00:05:00.760 --> 00:05:06.000 te compras un coche el software es completamente diferente con periodos potenciales de 10, 00:05:06.000 --> 00:05:11.640 15, 20 años y los reguladores deberían de centrarse en ese aspecto de forma prioritaria. 00:05:11.640 --> 00:05:17.600 Hablando de desarrollo de software, ¿os acordáis que hace unos días comentábamos que desde 00:05:17.600 --> 00:05:23.760 Rusia acusaban a Apple de colaborar con la NSA y diferentes agencias de inteligencia 00:05:23.760 --> 00:05:31.080 estadounidenses para lanzar un exploit capaz de infectar dispositivos iPhone y iPad de 00:05:31.080 --> 00:05:39.200 forma completamente silenciosa y con un acceso remoto completo? El exploit se llama TriangleDB, 00:05:39.200 --> 00:05:46.120 pronunciado de una forma más sencilla, y todo el misterio detrás de este exploit se 00:05:46.120 --> 00:05:54.800 llama Operación Triangulation. Entonces ahora tenemos que el grupo Kaspersky ha hecho un 00:05:54.800 --> 00:05:58.880 análisis mucho más en profundidad, o al menos lo ha publicado más allá de lo que 00:05:58.880 --> 00:06:05.400 publicó el mes pasado, y tenemos un repaso técnico de muchísimas de las operaciones 00:06:05.400 --> 00:06:10.400 que hacía este exploit, una vez que entraba dentro de un smartphone, cómo entraba, cómo 00:06:10.400 --> 00:06:16.080 se comunicaba y qué es lo que podía hacer. Dicen que han estado seis meses vigilándolo 00:06:16.080 --> 00:06:23.280 en diversos dispositivos infectados y francamente es increíble. Y precisamente lo que ha lanzado 00:06:23.280 --> 00:06:30.800 Apple hace dos días es un juego de dos parches para solucionar los fallos que estaban utilizando 00:06:30.800 --> 00:06:37.320 estos exploits, que eran tanto en el kernel del propio sistema operativo como en WebKit. 00:06:37.320 --> 00:06:43.280 A día de hoy, más allá de aquellas acusaciones por parte de los servicios rusos de una colaboración 00:06:43.280 --> 00:06:49.520 entre Apple y la NSA, de la que de momento no tenemos pruebas, nos falta saber desde 00:06:49.520 --> 00:06:55.720 cuándo llevaba esto disponible, cuántos dispositivos en todo el mundo estaban infectados 00:06:55.720 --> 00:07:01.760 y a quién pertenecían, para poder más o menos intentar ubicar los objetivos de esta 00:07:01.760 --> 00:07:07.840 campaña de ciberataques. Lo que sí es remarcable, amigos, es nuestro 00:07:07.840 --> 00:07:11.320 patrocinador de esta semana, ya sabéis que es Ransdack Technologies, la división de 00:07:11.320 --> 00:07:16.760 la consultoría de IT del grupo Ransdack, que te ayudan con la gestión e implementación 00:07:16.760 --> 00:07:21.360 de servicios tecnológicos especializados a tu negocio, a tus empresas, a todo aquel 00:07:21.360 --> 00:07:26.600 que lo necesite, por ejemplo, para automatización de procesos, gestión de datos y cualquier 00:07:26.600 --> 00:07:34.280 proyecto realmente fuerte de IT, porque Ransdack Technologies pone a disposición de tu empresa 00:07:34.280 --> 00:07:39.160 más de 15.000 profesionales especialistas capaces de llevar a cabo cualquier proyecto 00:07:39.160 --> 00:07:43.640 que tu empresa necesite. Pero recuerda que Ransdack Technologies también 00:07:43.640 --> 00:07:48.320 selecciona para ti a los profesionales cualificados que se adapten a la misma velocidad para seguir 00:07:48.320 --> 00:07:54.740 aprovechando todas estas oportunidades desde dentro de tu empresa y encontrar y garantizarte 00:07:54.740 --> 00:08:02.240 los candidatos que tu negocio necesita. Tenéis toda la información, como siempre, en Ransdack.es. 00:08:02.240 --> 00:08:08.240 Y nos volvemos a San Francisco y, como no, hablar del tema particular de estos últimos 00:08:08.240 --> 00:08:13.920 meses en este podcast, cada vez que hablamos de esta ciudad, que es de los coches autónomos, 00:08:13.920 --> 00:08:19.960 que siguen expandiendo las flotas y ahora mismo tenemos una guerra abierta entre parte 00:08:19.960 --> 00:08:25.980 de las autoridades locales y las empresas que mantienen y gestionan estas flotas de 00:08:25.980 --> 00:08:31.760 coches autónomos, estos robotaxis, como queráis decirlo. Y dentro de esta guerra ha entrado 00:08:31.760 --> 00:08:39.240 de lleno la propia jefa del Cuerpo de Bomberos de San Francisco, que ha sido muy, muy tajante 00:08:39.240 --> 00:08:44.800 con las declaraciones sobre estos vehículos, principalmente de dos compañías, Waymo y 00:08:44.800 --> 00:08:50.080 Cruise. Dice que es posible que sea en el futuro, pero que no están preparados para 00:08:50.080 --> 00:08:57.160 el día a día, que hay un montón de cosas que deberían de mejorar. Y cita que durante 00:08:57.160 --> 00:09:03.280 este año, estos seis primeros meses, ha habido 39 veces que los servicios de emergencias, 00:09:03.280 --> 00:09:09.800 los coches de bomberos, las ambulancias, etcétera, de la ciudad se han visto interrumpidos o 00:09:09.800 --> 00:09:15.600 bloqueados o atascados por coches de estas dos compañías que no deberían de estar 00:09:15.600 --> 00:09:20.720 ahí. Algunos casos ya los hemos comentado en el programa en el pasado y en el artículo 00:09:20.720 --> 00:09:24.880 que os dejo en las notas del episodio nos dan algunos más. Por ejemplo, uno que me 00:09:24.880 --> 00:09:30.320 parece completamente loco y es un coche de Waymo que había aparcado o se había quedado 00:09:30.320 --> 00:09:35.960 parado a las puertas de la salida de un parque de bomberos. Entonces no podían salir los 00:09:35.960 --> 00:09:43.000 camiones sin llevárselo por delante y causar destrozos en la zona, lo cual me parece increíble 00:09:43.000 --> 00:09:50.160 y no me extraña que esté irónicamente bastante quemada la jefa del cuerpo de bomberos. Ya 00:09:50.160 --> 00:09:55.780 digo, hay muchísimo que mejorar y creo que las policías, etcétera, deberían de tener 00:09:55.780 --> 00:10:03.160 alguna especie de botón o sistema informático que obligue y comunique a todos los coches 00:10:03.160 --> 00:10:07.000 que salgan de esas zonas. 00:10:07.000 --> 00:10:10.280 Seguimos hablando de inteligencia artificial. Una noticia rápida que tiene que ver con 00:10:10.280 --> 00:10:15.240 el deporte, de hecho comienza ya el torneo de Wimbledon, que va a estar analizado por 00:10:15.240 --> 00:10:20.520 IBM en tiempo real, utilizando algunos de sus avances en aprendizaje automático y en 00:10:20.520 --> 00:10:25.480 reconocimiento de vídeo van a poner dos cosas que me parecen bastante chulas. La primera 00:10:25.480 --> 00:10:30.580 es un sistema de comentarios automatizados para las jugadas más importantes en todas 00:10:30.580 --> 00:10:36.280 las pistas. Obviamente, más allá de los grandes partidos y los grandes juegos, hay 00:10:36.280 --> 00:10:43.320 un montón de tenistas jugando en paralelo constantemente durante días y hay un montón 00:10:43.320 --> 00:10:49.240 de información que todos los años en este tipo de torneos se queda perdido. Entonces 00:10:49.240 --> 00:10:55.080 esto puede acelerarlo y crear resúmenes de las partes más interesantes de todas las 00:10:55.080 --> 00:11:01.600 partidas del torneo y por otra parte una especie de estadísticas predictivas sobre los partidos 00:11:01.600 --> 00:11:07.400 y sobre los diversos jugadores según vaya sucediendo el torneo que van a estar disponibles 00:11:07.400 --> 00:11:11.960 tanto en la aplicación como en la página web en tiempo real. Me parece algo muy chulo, 00:11:11.960 --> 00:11:16.440 me parece que es algo que deberíamos de ver más a fondo en el deporte. Creo que por ejemplo 00:11:16.440 --> 00:11:22.880 el béisbol es un pionero en este aspecto, pero yo creo que esta es una de las partes 00:11:22.880 --> 00:11:29.520 en la que la tecnología puede ayudar muchísimo más con todos los deportes e incluso todas 00:11:29.520 --> 00:11:35.520 las categorías donde no se puedan dedicarle los grandísimos recursos que se dedican a 00:11:35.520 --> 00:11:42.120 las grandes ligas de los deportes más populares. Y por otro lado parece que por fin han diseñado 00:11:42.120 --> 00:11:49.240 un sistema casi perfecto, hago énfasis en el casi, para identificar imágenes sintéticas, 00:11:49.240 --> 00:11:56.120 es decir una huella invisible que se quedaría presente en todo el material que produzca 00:11:56.120 --> 00:12:02.300 DALI, que produzca Mid Journey, Stable Diffusion, etcétera, de tal forma que para un humano 00:12:02.300 --> 00:12:09.440 es invisible pero es rápidamente identificable para un software en caso de que se necesite 00:12:09.440 --> 00:12:16.040 saber si eso ha sido una imagen digital o una imagen sintética o algunos datos más. 00:12:16.040 --> 00:12:21.320 Todo este tipo de herramientas son muy importantes, en este caso es una filigrana matemática 00:12:21.320 --> 00:12:28.240 en forma de anillos concéntricos que se establecen dentro del ruido de fondo inicial cuando se 00:12:28.240 --> 00:12:35.740 va a generar esta imagen y que es mucho mucho mucho más fuerte y resiste en su verificación 00:12:35.740 --> 00:12:42.140 incluso después de muchísimas modificaciones a la imagen. Rotarla, recortarla, cambiarle 00:12:42.140 --> 00:12:48.920 los colores, sustituir partes, poner cosas encima, etcétera. Es un paso de gigante pero 00:12:48.920 --> 00:12:55.520 a su vez esto va a depender de que se implemente por parte de los grandes desarrolladores de 00:12:55.520 --> 00:13:02.960 este tipo de plataformas digitales. No me cabe duda que OpenAI, Microsoft, Google, etcétera, 00:13:02.960 --> 00:13:08.160 van a ofrecer este tipo de elementos en el futuro pero en las herramientas de código 00:13:08.160 --> 00:13:14.120 abierto lo veo más difícil porque precisamente son de código abierto. Quien te dice a ti 00:13:14.120 --> 00:13:21.800 que aunque la versión principal lo implemente no haya a los pocos días un fork que lo deshabilite 00:13:21.800 --> 00:13:27.840 y la gente decida utilizar estas versiones alternativas. Pero bueno, el mecanismo me 00:13:27.840 --> 00:13:33.320 ha parecido muy interesante, muy resistente y por eso digo que es casi perfecto porque 00:13:33.320 --> 00:13:38.000 en el paper que os dejo en las notas del episodio sus desarrolladores explican bastante bien 00:13:38.000 --> 00:13:46.240 los límites que han encontrado pero es la mejor forma que hemos tenido hasta la fecha. 00:13:46.240 --> 00:13:51.800 Y nos despedimos hablando de bastantes fallos de seguridad en GitHub a la hora de potenciales 00:13:51.800 --> 00:13:59.600 secuestros de repositorios, algo que GitHub debería de mejorar bastante porque es potencialmente 00:13:59.600 --> 00:14:06.480 muy peligroso y de que Intel parece que por fin ha hecho oficial la independencia de su 00:14:06.480 --> 00:14:13.600 unidad de fabricación de semiconductores. No es que se vaya a dividir Intel en dos empresas, 00:14:13.600 --> 00:14:21.240 simplemente hay dos pequeñas divisiones de fabricación y de clientes que se van a hacer 00:14:21.240 --> 00:14:27.600 una división mucho más fuerte y financieramente independiente pero aún así va a permanecer 00:14:27.600 --> 00:14:33.240 dentro de la propia matriz de Intel. Esto es algo que muchos recordaréis, Intel ya 00:14:33.240 --> 00:14:40.400 lo prometió y lo contó en 2021 que era el futuro, ya ha llegado y ahora esta división 00:14:40.400 --> 00:14:46.480 va a poder utilizar todas las grandes fábricas de Intel para fabricar procesadores para otras 00:14:46.480 --> 00:14:52.840 empresas. Más allá de un acuerdo que contaron hace unos meses con MediaTek no tenemos nada 00:14:52.840 --> 00:14:59.520 claro de quiénes van a ser los futuros clientes de esta nueva Intel porque no han dicho nada 00:14:59.520 --> 00:15:03.400 pero bueno de momento con esto lo dejamos por hoy. 00:15:03.400 --> 00:15:09.000 Os vuelvo a insistir que esta semana que viene a partir del día 26 lunes no va a haber podcast 00:15:09.000 --> 00:15:14.520 diario lo siento muchísimo pero voy a pasar bastantes bastantes ratos fuera de casa lejos 00:15:14.520 --> 00:15:20.640 de ordenadores etcétera y no voy a poder atender la actualidad así que consideradlo 00:15:20.640 --> 00:15:26.240 como si fuera una semana de vacaciones en este sentido y nos vemos cuando vuelva con 00:15:26.240 --> 00:15:34.680 más noticias de tecnología.