Elon Musk en Twitter HQ con los devs que se quisieron quedar.
Aquí lo tenemos claro desde siempre: no existe la nube, es el ordenador de alguien más. Lo mismo con las redes sociales. No importa si la propiedad de las empresa que la gestionan es de una sola persona o si ésta cotiza en bolsa. Lo que escribas allá lo usarán los dueños para lo que más les convenga a ellos, con el único límite de lo que les permita la ley.
Yo en lo particular he decidido seguir con mi cuenta en Twitter como si no hubiese pasado nada. Bueno, esto no es del todo cierto, porque la compra en sí y lo que está sucediendo en estas primeras semanas después de la compra está siendo inspiración de los tweets, conversaciones y memes más entretenidos que recuerdo. Lo único extra que he hecho es una copia de seguridad de los veintipico mil mensajes que llevo publicados en 14 años de uso, por si los agoreros aciertan y Twitter se cae.
¿Gestión del archimillonario? El tipo es un show. Desde la entrada a la recepción de los HQ en San Francisco en plan «let that sink in» (juego de palabras intraducible: «deja entrar a ese lavamanos» y «a ver si se hacen a la idea» se dicen igual en inglés) es un no parar. Pero espectáculo aparte, es lo que pasa en cualquier empresa cuando entra a su consejo de dirección lo que se conoce como «accionista activista», alguien que tiene ideas muy claras sobre cómo hacer que la empresa de la que es copropietario puede tener más beneficios. El accionista activista toma el control de la junta directiva, que suele designar a un CEO de su confianza a la cabeza, y es éste quien lo pone todo patas arriba. Creo que Musk tiene un problema en delegar cuando la cosa está peliaguda y ha asumido él mismo ese rol, que va más allá del que le gusta (jefe de ingeniería, I+D y estrategia), quizás de ahí que haya mucho más ruido del habitual en estas circunstancias. Y es que generalmente sí es cierto que en la empresa comprada había fallos de gestión, probablemente mucho apoltronamiento y parálisis y sí es cierto que se podía haber sacado más rendimiento a los activos existentes, pero no olvidemos que el diablo está en los detalles y que darle la vuelta a un mostrenco empresarial toma sangre, sudor y lágrimas. Lo he visto tres veces en mi carrera profesional, eso me hace añadir elementos a esa expresión: infartos de miocardio y entierros. Sobre todo si los cambios son drásticos y los tiempos, breves, como está sucediendo en Twitter.
En el caso de compras y absorciones e empresas, antes de concretar la compra, al que va a abrir la billetera se le da acceso exclusivo a información relevante de la empresa a comprar. En inglés, a ese ejercicio de evaluación se le dice «due diligence». Se te da la oportunidad de echarte para atrás si hay discrepancias de calado entre lo que te «han vendido» y lo que tú averiguas. Y ese es el origen de todos los toma y daca veraniegos entre Musk y Agrawal en relación a los bots, dato muy importante para Musk, porque de un bot no se pueden obtener réditos, aparte de la naturaleza tendenciosa y manipuladora de muchas de las redes de este tipo de cuentas de usuario sin una persona de verdad detrás. Según lo que él mismo publicó, lo averiguado en la «due diligence» no fue del gusto de Musk, por lo que quiso cancelar la compra. De ahí la denuncia de los accionistas de Twitter, que veían cómo se les escapaba la oportunidad de quitarse de encima el muerto de Twitter (empresa hipertrofiada que nunca dio beneficios) pagándoseles la acción a precio de oro, y Musk, que creo tiene una relación sana con el dinero (llegado un cierto punto es un concepto teórico) diría un «fuck it, why not, it’s gonna be a hell of a ride» y recogió el guante. Aquí estamos hoy. Un cambio radical de mentalidad en la empresa, primando la ingeniería y el rendimiento por encima de todo lo demás, y el consecuente cambio de plantilla. Ya para otra queda explicar cuando tras el infarto y muerte de mi jefe (como mencionaba antes, ya llevo tres…), los nuevos gerifaltes me pidieron la evaluación de los técnicos de mi departamento, los listados con el número de líneas de código de cada quién (ya sé…) de los últimos seis meses para que la «limpieza» la decidiese una hoja excel.
Por aquí seguimos el tema con interés y palomitas.
¡No dejemos que pase un año entero sin publicar siquiera una entrada! Desde luego, ha de ser sobre la pandemia.
Estamos casi todos con la pauta de vacunación completa (dos dosis los de Team Pfizer, Astra Zeneca, Sputnik, una los de Moderna y los CanSinos) y nuestros seniors ya van por el refuerzo. Eso es genial y está siendo crucial a la hora de controlar la pandemia.
En verano hemos vuelto a viajar y se ha estandarizado el uso de una cosa llamada «pasaporte COVID». En el caso de los residentes en la Unión Europea se trata de un documento estandarizado para todos los países de la Unión. En otros países se dispone de los certificados de vacunación, muchos manuscritos, pero en fin, nos hemos acostumbrado a viajar con el cachopapel en la mano (o con su versión PDF o fotografiada en el teléfono móvil). Qué les voy a contar que no sepan ya.
Bueno, pues yo vengo a hablarles de mi libro del concepto de teatro de seguridad ideado por Bruce Schneier y muy bien explicado por Versvs.
En campechano, se trata de montar un paripé para que la gente se quede con la idea de que se está haciendo algo al respecto de una situación que da miedito.
Pues ahí les va. Tenemos conocidos que han dado positivo por COVID19 y que son asintomáticos (recordemos que incluso sin síntomas pueden contagiar), que están confinados y, adivinen… cuyos pasaportes COVID salen más verdes que una lechuga del Mercadona. Vamos, que si salen a la calle y se van al cine, al bar, al restaurante, al IKEA, a donde les dé la absoluta gana, mostrando el QR, nadie los va a detener. No digo que lo estén haciendo, porque son gente responsable, pero que podrían, podrían.
La #bonillista de hoy, escrita por Txetxu Velayos y tratando el tema del incendio del proveedor de servicio de almacenamiento OVH, los SLA (acuerdos de nivel de servicio) y qué diablos pasa cuando lo impensable sucede, me ha traido a la mente mis viejos tiempos de SysAdmin, así como esta pegatina. Agárrense, que vienen batallitas que ni las de la mili:
Vamos al tajo. Yo salí de la universidad como «computer scientist» de los de verdad: no me dejé ni una asignatura de matemáticas, ni de lógica, ni una de complejidad algorítmica, sistemas formales, inteligencia artificial. Me quité de encima la electrónica en cuanto me lo permitió el plan de estudios, aunque me chuté todas las de arquitectura de computadoras por lo flipante de la optimización de algoritmos que se explicaba, y la verdad sea dicha, las cosas en las que pensaba estaban muy distantes de la máquina o incluso de lo que se esperaba de un informático en el mercado laboral español de los años 90. Así que me fui… (insert other batallitas here…)
… y por azares del destino, ¡¡¡muy pronto me vi trabajando de administradora de sistemas!!! 200 servidores Windows NT distribuidos por toda Europa, medio centenar de ellos en el Data Center de la oficina.
Eran unos tiempos muy curiosos. ¿Abrías una oficina o una fábrica en, pongamos por ejemplo, Hannover? Pues entonces tenías que deplegar al menos un servidor de ficheros y de impresión local, que además te servía de controlador de dominio. ¿Y cómo desplegabas? «Facilísimo». Hablabas por teléfono con tu proveedor de hardware (por ejemplo Compaq), acordabas con él la especificación del servidor y te mandaba el presupuesto. Lo imprimías, conseguías la firma de tu jefe y lo llevabas al departamento de Compras, que emitía el pedido. Un mes después más o menos te llegaba.
Te llevabas las cajas a tu mesa de trabajo, desembalabas la carcasa, los discos, el procesador, la memoria, otras tarjetas que necesitases (¡por ejemplo, una de fax!), pero normalmente eso era todo. Lo montabas todo (usando las manos, destornilladores,..), sacabas de tu cajón los CD’s y te ponías a instalar el sistema operativo, otros programas servidor (¡hola, MTA’s de MSMail y Schedule+!), lo dejabas todo listo para que en destino cambiases la direccion IP, conectases a la red y ¡todo listo!
Usar una imagen era impensable, el Ghost fallaba como escopeta de feria. Yo me automatizaba todo lo posible con DOS scripting (un conocimiento que muchos años después me ha hecho parecer una diosa nubia ante compañeros bastante buenos pero que en la vida habían visto una línea de comandos), todo y ello había muchísima componente manual en lo que hacíamos.
En destino (Hannover en este ejemplo) significaba: Si estabas a menos de 500 Km de distancia sin el Canal de la Mancha por el medio, metías tu servidor al coche, te pegabas un día conduciendo y al día siguiente montabas (si era el primero, también tenías que montar el rack). Si no, enviabas el servidor montado por paquetería, te pillabas un avión y allá ya acababas.
Esta última fase del trabajo podía durar de 15 minutos (colocar servidor en el rack, arrancar, cambiar la IP, conectar a la red, reiniciar) a 8 horas (hacer la instalación completa desde cero). El año 2000 me pilló con este trabajo, así que la cantidad de horas extra actualizando / sustituyendo servidores fue indecente. Idem la cantidad de puntos de línea aérea que acumulé y las ciudades que pude conocer cuando se alineaban los astros y la máquina arrancaba a la primera. De la complejidad algorítmica, ni rastro.
Dónde está el LISP, los sistemas expertos, la completitud de Turing y las gramáticas de Chomsky, que yo las vea.
Se imaginan los LOLZ que me pego yo sola cuando alguien jovencito se estresa por hacer un deploy de una máquina en AWS hoy en día 🙂 Ya en serio, esta experiencia me permite apreciar y agradecer todo lo que el IaaS, el PaaS, el SaaS, la nube, el DevOps y resto de siglas nos permiten hacer sin despeinarnos. La verdad, me quito el sombrero ante AWS, que inició todo esto, y resto de proveedores que no se quedan atrás .
Aparte de este trabajo eminentemente técnico y machacón, también nos encargábamos de la seguridad, los parches, el soporte, el diseño de la configuración de nuevos equipos y nuevas versiones de software… y las tareas que considerábamos administrativas y aburridas, no por ello menos importantes, al menos para nuestro management, que, quizás por aquello de que los servidores eran trastos con los que convivíamos, no entes virtualizados de varios niveles de abstracción, entendían lo que teníamos entre manos y podían ejercer sin problemas su sentido común.
Sentido común en este contexto es:
¿Cómo diablos sigo operando mi negocio (vendiendo, produciendo, entregando, cobrando facturas, pagando proveedores y nóminas) si me quedo sin todo este trasterío?
¿Cómo diablos recupero todo este trasterío, si se destruye, por ejemplo debido a un incendio? Recuperación de la información así como restauración del servicio.
A lo primero se le llama Business Continuity Plan. A lo segundo, Disaster Recovery Plan. Era nuestra obligación que ambos planes existiesen, estuviesen actualizados y fueran coherentes, aunque el primero lo compartíamos con las áreas operativas. Ellos sabían: ¿Cuál era el nivel de servicio que proporcionábamos a nuestros clientes? ¿Disponibilidad de atención a cliente, de tiempos de entrega, de stock de producto, todo ello por obligación contractual? En base a todo ello se escribía el plan y se tenía todo preparado por si había que utilizarlo. Eso significaba desde tener libretas de papel y bolígrafos para poder capturar pedidos, así como una preorden de oficina por si hay que mover allá el call center, poder enrutar las llamadas entrantes a unos cuantos teléfonos móviles, hasta tener los sistemas de información duplicados y poder hacer el cambio en caliente en caso de no disponibilidad del sistema principal.
Antes de explicar el Disaster Recovery Plan, déjenme hablar de backups o copias de seguridad. Antes de que se inventaran los backups por red, se hacían copias de respaldo de todos los servidores cada noche. Una vez a la semana hacíamos la copia completa, el resto de días solo la incremental. Y cada mañana enviábamos por paquetería los cartuchos de backup a la empresa que gestionaba los backups. Los cartuchos, por cierto, no se insertaban solos, había que empujarlos y a la mañana siguiente, sacarlos. Con las manos. En ubicaciones muy remotas contábamos con la valiosísima colaboración de la señora de la limpieza (que era la última persona en dejar la oficina por la tarde) para este menester.
Para el Disaster Recovery Plan, teníamos contratado un servicio con esa misma empresa que, caso de necesitarlo, ponía a nuestra disposición el hierro (servidores) y los CDs y los manuales que nosotros les hubiésemos proporcionado, así como la última versión de backup que habían recibido de nosotros. A esa ubicación se enviaba un equipo de técnicos (nosotros) para reconstruir todo y llevarlo a un punto que pudiera restablecerse el servicio de sistemas de información.
Lo más divertido es que en el plan incluíamos un ejercicio anual de prueba del propio plan (un quién vigila al vigilante, vamos). Me tocó participar una vez: coche en Manchester desde Londres a toda velocidad (nos cronometrábamos para ver cuán rápido podíamos restablecer el servicio), trabajar 16-20 horas seguidas hasta que todo quedase (y luego un fiestón mancuniano, una siestaza y de vuelta al sur). Y si no quedaba, pues entonces teníamos otra semana de trabajo garantizada identificando el por qué, corrigiendo los fallos en el procedimiento y volviendo a documentar.
Y vaya si son necesarios estos planes. Disaster Recovery no llegué a experimentar en vivo, Business Continuity Plan, sí. Nos explotó una empresa química en el polígono, nos evacuaron y se tuvo que montar sobre la marcha. Es una sensación increíble saber que tu pedantería a la hora de elaborar documentación ha significado que ningún paciente de EPOC de la campiña inglesa se ha quedado sin su entrega de oxígeno medicinal.
Volvamos a la actualidad: No existe ninguna razón por la cual tanto el Business Continuity Plan como el Disaster Recovery Plan hayan dejado de ser necesarios. Creo que las nuevas generaciones, especialmente las de management, están practicando el proverbial «ojos que no ven, corazón que no siente». Has migrado tu infraestructura a la nube. Cierto, ya no necesitas dos meses para aprovisionar hardware. Ya no necesitas pagarme el avión a Hannover, ni siquiera pagarme el sueldo. Pero la magia no existe. Solamente has externalizado la gestión de la infraestructura informática, eso significa que alguien más se ocupa de ella, pero no por ello es, por arte de contrato, irrompible: it’s someone else’s computer! Sigue siendo tu resonsabilidad estar preparado porque shit happens also on the cloud, tienes que saber cómo seguir dándole servicio a tus clientes (Business Continuity Plan) así como disponer de un Disaster Recovery Plan, o, en castellano común, cómo no perder irremediablemente lo más importante de una empresa del siglo XXI: tus datos, tu información, tu inteligencia. El poder echarle la culpa a otro con el contrato en la mano no te los va a devolver.
Leo el artículo de Bruce Schneier sobre el hackeo masivo a la administración estadounidense y hasta el tato en realidad (Microsoft también) debido a una vulnerabilidad en el protocolo de seguridad del omnipresente producto Orion de la empresa Solar Winds. Da qué pensar lo frágil que es la sociedad actual a este tipo de soluciones, y pensando talebianamente, me pregunto qué podemos hacer a modo personal ya no para ser robustos (a la Sara Connor) sino para ser antifrágiles a este tipo de situaciones.
Hace ya once añazos andábamos por aquí comentando con sorpresa que Microsoft estaba trabajando duro en el proyecto Natal. Acabaron llamándolo Kinect, ya saben, el control de la consola XBox que usaba una cámara.
Afirman que hay más problemas de privacidad con el teléfono que llevas en el bolsillo que con este nuevo dispositivo.
Lo triste es que es cierto.
Lo más triste aún es que esos drones con cámara van a salir del hogar y pronto, muy pronto, los tendremos dando vueltas por nuestros pueblos y ciudades.
Y es que a la vez que el dron, Amazon ha anunciado la red Sidewalk, una especie de fon, o mesh network, o como quieran decirle, para que el excedente del internet de tu casa lo puedan usar los dispositivos IoT Amazon de tus vecinos si su conectividad va flojilla (y viceversa).
Obvio que esos drones callejeros van a usar Sidewalk.
La novedad es que el paper que presentaron el año pasado se ha implementado. Se trata de un robot cirujano capaz de realizar implantes de 1024 electrodos en el cerebro. Una cosa interesante es que tiene la capacidad de evitar la vascularidad, o sea: nada de sangrado. Eso sí: te llevas una trepanación y sustituyen parte de tu cráneo por un material de características similares.
El implante se comunica con el exterior a través de Bluetooth Low Energy (BLE) y dicen que las comunicaciones entre todas las capas van cifradas.
Lo han probado con cerdos. Los han implantado y también los han retirado, porque el concepto es el de un procedimiento reversible, ya sea por cambio de opinión, o para actualizar con un modelo nuevo. El cerdo es similar al humano en su fisiología y además se pega cabezazos por todas partes.
La primera parte de la demostración era la lectura de las neuronas disparándose en reacción a estímulos en el morro de un cerdo que se paseaba por su jaula en el estudio de grabación.
La segunda parte de la demostración fue poner a un cerdo en una corredora, y ser capaces de predecir la posición de las articulaciones de sus patas en base a la lectura de los disparos de las neuronas.
Obviamente el implante de cada uno de esos cerdos se hacía en las respectivas regiones del cerebro que controlan el morro y la motricidad. No es «un solo implante para todas las funcionalidades» (al menos con el número de electrodos actual y hasta que logren implantar varios órdenes de magnitud más).
No hubo demo, pero se nos dice que el implante es de «lectura y escritura», es decir, que se pueden estimular neuronas para que se disparen.
Las primeras aplicaciones, como ya había anunciado Musk a través del blog de Wait but why?, son médicas. Las obvias son visión para invidentes y motricidad para paralíticos.
Han obtenido el visto bueno de la FDA para seguir adelante con sus investigaciones clínicas.
Están a punto de iniciar el reclutamiento del primer estudio clínico: motricidad de tetrapléjicos. Se explica que se hará un «bypass»: Neuralink se comunicará con otro implante que esté más abajo de la zona de la columna lesionada, y de ese modo el paciente podrá entrenar a su cerebro para que controle sus miembros.
Hubo una sesión de preguntas y respuestas con todos los empleados de Neuralink.
Sí se mencionó Dark Mirror y sí se anticipa la capacidad de hacer «backups» de los recuerdos de las personas.
Elon sí mencionó el tema de riesgo a nuestra especie que él advierte en la emergencia de una inteligencia artificial avanzada.
Hay algo de cachondeo en mi TL de Twitter sobre el nuevo anuncio de Amazon: Halo, un wearable que te dice si estás enfadado o si estás gordo (según titulares nacionales, The Verge da algo más de detalle aparte del chistecito).
Pasando esto en la semana que Elon Musk hace su presentación anual de los avances de Neuralink, y se dice, se cuenta, se rumorea que será una demo con humano.
De repente me he acordado de algo que escribimos por aquí hace muchos años (febrero de 2007 y enero de 2008 para ser más precisos) cuando Microsoft, el insensible, o sea, el anterior a Satya Nadella, compartió un concepto de ordenador que se pudiera armonizar con su propietario para proporcionarle información y tareas conforme a su estado de ánimo.
Es llamativa la reacción de rechazo que tales planteamientos generaban hace una década y pico. Ahora ya estamos habituados a que nos escuchen y vean constantemente, y hasta muchos estarían dispuestos a que les coloquen un «puerto» detrás de la oreja para facilitar la integración persona-máquina. Y es que prácticamente somos ciborgs, nuestro smartphone es un apéndice más. Ante una duda ¿acaso no piensan en cómo buscar la información en lugar de intentar recordarla?
El otro día cayó en mis manos este artículo de Gizmodo, cortesía de Pere, a raíz de una conversación sobre «fitness trackers» y su utilidad.
Parece ser que los últimos tiroteos en Estados Unidos no han sido suficiente desgracia. Ahora el presidente de ese país ha anunciado que para evitarlos hay que inventar una especie de «Minority Report» y qué mejor que usar los datos de Fitbit para identificar qué ciudadanos están a punto de perder la cabeza y echarse al mall (y después al monte) con un rifle automático.
¿Dónde acoger a las personas que se van a dedicar a ello? Fácil, en el HARPA. No, no uno de los que ilustran el post. Es como el DARPA pero para temas de salud: una organización gubernamental secreta dedicada a desarrollar tecnología para fines estratégicos.
Que lo primero que se le ocurra a las autoridades estadounidenses para mejorar la salud del país, que el primer encargo de esta futura HARPA sea un sistema predictor de problemas de salud mental de su ciudadanía es… enloquecedor.
En el evento AWS re:Invent de 2017, Amazon anunció su producto de reconocimiento de imagen «Rekognition«. Este evento anual es mareante, no solo por la cantidad de productos que se anuncian, sino por la creciente facilidad para integrarlos, en una especie de Lego gigante, donde los límites de lo posible los dictan tu imaginación y tu bolsillo. En el re:Invent de 2018 anunciaron más cosas todavía (¡estaciones de recepción de señales de satélites «on demand»!), pero eso lo dejamos para otro post.
Vuelvo a 2017. Cuando oímos hablar de «Rekognition», algunos nos echamos a temblar. Porque funciona no solo para imágenes estáticas, sino para videos, incluido en streaming, y porque si te pones el gorro distópico, no dejas de pensar en malos usos para esa tecnología.
Pues este año ha salido a la luz una patente publicada por Amazon que combina «Rekognition» con el producto estrella de Ring, una compañía recién comprada por el grupo de Jeff Bezos. Adivinen qué fabrica Ring: timbres para la puerta. Ahora imaginen todos los timbres, todos los telefonillos, con una cámara que está constantemente grabando y que constantemente esté utilizando «Rekognition» para identificar caras y después compararlas con «fotomatones» de personas con un antecedentes penales. Conecten el sistema con la centralita de la policía local. Y añadan a la mezcla que el reconocimiento facial es especialmente fallón cuando se trata de personas de faz morena o mujeres. El último ingrediente es que estos sistemas sofisticados dan una sensación de falsa seguridad: se les supone una infalibilidad que no tienen.
¿El resultado? Una pesadilla legal para los pobres «falsos positivos» que decidan salir a pasear y tengan la mala suerte de ser filmados por un timbre «Ring».
Aquí se pueden leer lo mismo que explico yo, pero más bonito y en inglés: ACLU Northern California.
Tecnologías de la información y la comunicación, libertad individual, derecho a la privacidad. ¿Cómo lograr que los avances en lo primero no afecten negativamente ni a lo segundo ni a lo tercero?
