Llegamos a ustedes gracias a:



Conversando con...

Linus Torvalds, creador de Linux

Linux y sus 25 años: La evolución y el futuro de Linux

[26/09/2016] La última vez que tuve la oportunidad de entrevistar a Linus Torvalds fue en el 2004, cuando la versión 2.6 del núcleo de Linux había sido lanzada. Yo estaba trabajando en un artículo llamado "Linux v2.6 crece en la industria. La oración de apertura fue "Si los proveedores comerciales de Unix no están preocupados por Linux aún, deberían estarlo ahora. Estas palabras resultaron siendo bastante proféticas.

Más de 12 años después -muchas vidas en el mundo de la computación- a Linux se le encuentra en todo el mundo tecnológico. Lo que empezó como un proyecto individual ahora involucra a miles de desarrolladores. En este aniversario número 25, contacté a Torvalds una vez más para ver si tenía tiempo para responder algunas preguntas sobre los orígenes y evolución de Linux, el pulso actual de la comunidad de desarrollo de Linux y que perspectiva tiene en relación a los cambios futuros de los sistemas operativos y el hardware. El aceptó cortésmente ser entrevistado.

La siguiente entrevista ofrece el punto de vista de Torvalds respecto al futuro de la x86, cambios en el desarrollo del kernel, los contenedores Linux, y cómo los cambios en la computación y los modelos de upgrade de los sistemas operativos de la competencia podrían afectar a Linux en el largo plazo.

Los orígenes de Linux se dieron en ambientes de bajos recursos, y los procedimientos para el desarrollo de códigos fueron necesariamente ligeros. Esto no es así en la mayoría de casos de uso hoy en día. ¿Cómo cree que eso ha afectado a los procedimientos de desarrollo para del kernel o el sistema operativo en general?

Creo que su premisa es incorrecta: Los orígenes de Linux definitivamente no fueron de tan bajos recursos. La 386 fue la máquina más robusta que se podía comprar como estación de trabajo en ese entonces, y aunque 4MB o 8MB de RAM parecen muy poco hoy en día -y diría "ligeros-, en ese entonces no se sentía de esa forma para nada.

Así que, incluso hace 25 años, sentí como si tuviese memoria y recursos de sobra y para nada constreñidos debido al hardware. Y el hardware seguía mejorando, así que mientras Linux iba creciendo -y, quizás sea más relevante, conforme iban creciendo las cargas de trabajo para las cuales se podía usar Linux- nosotros seguíamos sin sentirnos muy limitados por los recursos de hardware.

Desde la perspectiva del desarrollo, creo que las cosas no han cambiado mucho. Si hay algo que mencionar, sería que en estos días las personas están intentando poner Linux en algunos ambientes integrados realmente pequeños (IoT); de hecho, tenemos desarrolladores que hoy en día se sienten más limitados que los desarrolladores del kernel hace 25 años. Suena extraño, dado que los dispositivos de IoT tienden a ser más poderosos que esa máquina 386 en la que empecé, pero hemos crecido (bastante) y las expectativas de las personas también han crecido.

Las limitaciones del hardware no han sido el mayor problema que afecta a los procedimientos de desarrollo, porque el hardware creció con nuestro desarrollo. Pero ciertamente hemos tenido otras cosas que afectan la manera en cómo hacemos las cosas.

El hecho de que Linux es un "negocio en serio, obviamente cambia la manera en que trabaja - uno tiene más reglas y necesita ser más considerado y cuidadoso respecto a los lanzamientos. La cantidad de personas involucradas también cambia radicalmente la forma en que uno desarrolla las cosas; cuando había unas pocas decenas de desarrolladores y todos podíamos enviarnos actualizaciones entre nosotros por correo electrónico, las cosas funcionaban de manera distinta a cuando existen miles de personas involucradas, y obviamente necesitamos una administración de control de la fuente y todo el modelo distribuido que tiene Git.

Nuestro modelo de desarrollo ha cambiado bastante en este cuarto de siglo, pero no creo que sea debido a las limitaciones del hardware.

¿Usted reconoce diferencias fundamentales entre los hackers del kernel más jóvenes versus aquellos de hace 20 años?

Es muy difícil ser introspectivo y lograr acertar. Yo no pienso que los desarrolladores del kernel sean muy distintos necesariamente; creo que el tamaño y la madurez del proyecto mismo es la diferencia más significativa.

Hace veinte años, el kernel era mucho más pequeño, y había menos desarrolladores. Era quizás, hasta cierto punto, más fácil ingresar al campo de desarrollo debido a esto: Existía menos complejidad en que pensar, y era más fácil destacarse y hacer (relativamente) una gran diferencia con una función grande y nueva.

Actualmente, es mucho más difícil encontrar alguna función grande que no haya sido inventada antes -después de todo, el kernel es un proyecto bastante maduro y existen toneladas de desarrolladores con experiencia, así que es más difícil destacarse. A la vez, tenemos mucha más infraestructura con la que las personas nuevas pueden involucrarse, y existen más controladores y soporte de hardware con los que uno se puede involucrar, así que en otros sentidos se ha convertido en algo mucho más sencillo. Después de todo, hoy en día usted puede comprar un Raspberry Pi por un precio no tan alto, e involucrarse en hacer cosas que 20 años atrás simplemente no se podían hacer.

Obviamente, el otro aspecto que ha cambiado es que 20 años atrás, uno se involucraba con Linux exclusivamente por el reto técnico. Hoy en día, puede fácilmente verse como una carrera: es un proyecto grande con muchas compañías involucradas, y en ese sentido el mercado ha cambiado radicalmente. Pero aún pienso que uno termina teniendo que ser una persona con una mentalidad bastante técnica para introducirse al campo de la programación del kernel, y no creo que el tipo de persona haya cambiado, pero quizás ha significado que las personas que hace 20 años pensaban, "No tengo suficiente dinero para experimentar con un proyecto de juguete, sin importar que tan interesante sea, ahora ven a Linux como un lugar donde no solo pueden encontrar un reto técnico interesante, sino también un trabajo y una carrera.

¿Usted considera que el crecimiento de los lenguajes interpretados y de alto nivel, además de los métodos de codificación asociados están alejando a los desarrolladores talentosos del desarrollo de sistemas operativos internos?

No, para nada. Creo que es algo que principalmente expande el mercado, pero el tipo de personas interesadas en los detalles de nivel bajo y una interacción verdadera con el hardware aún van a ser atraídas por proyectos como el del kernel.

Los lenguajes de nivel más alto principalmente reflejan el hecho de que el espacio (y el hardware) se ha expandido, y aunque un lenguaje como C sigue siendo relevante para la programación de sistemas (pero C ha evolucionado un poco a través de los años), obviamente existen muchas áreas en las que C definitivamente no es la solución correcta y nunca lo será. No es una situación donde siempre se puede elegir (y no es una cuestión de todo o nada); es solo un reflejo de los tipos de problemas y limitaciones de recursos que enfrentan diferentes proyectos).

¿Qué piensa que le depara el futuro a la x86?

No acostumbro hacer predicciones, pero obviamente existe el patrón de "las máquinas pequeñas crecen, y todas las comparaciones históricas sobre cómo la PC creció y desplazó casi a todo lo que había encima. Y todo el mundo está observando a la tecnología integrada y a los teléfonos celulares y viendo como estos crecen mientras que el mercado de PC no crece tanto.

Esa es la trama obvia, y hace que muchas personas se emocionen con todo el tema de x86-vs.-ARM: "ARM va a crecer y desplazará a x86.

Al mismo tiempo, también existen unas pocas diferencias grandes. Una razón grande por la que las PCs crecieron y dominaron fue la facilidad para desarrollar en ellas, y además de haber toda una generación de desarrolladores que creció con computadoras en sus casas (y PC en particular), incluso si uno estaba desarrollando para una de esas máquinas grandes que las PC desplazaron eventualmente, con frecuencia se utilizaba una PC para hacerlo. Las máquinas del back-end pueden haber sido el hierro fuerte y serio, pero las máquinas del front-end eran con frecuencia las estaciones de trabajo de clase PC.

Cuando las PC crecieron, éstas desplazaron con facilidad a las máquinas más grandes porque uno tenía a estos desarrolladores que estaban acostumbrados al ambiente PC, y de hecho preferían bastante tener el mismo ambiente de desarrollo que su ambiente de despliegue final.

Ese patrón no está manteniéndose para la comparación x86-vs.-ARM. En realidad, está revertido; incluso si está desarrollando para el ecosistema ARM más pequeño, será casi seguro que esté utilice una PC (ya sea Linux, MacOS, o Windows) para desarrollar, y simplemente haga un despliegue en ARM.

En ese sentido bastante real, en la comparación histórica sobre cómo las PC x86 conquistaron el mercado de computación, ARM de hecho parece ser más como el hardware grande que fue desplazado y menos parecido a la PC que lo desplazó.

¿Qué significa todo esto? No lo sé. No estoy viendo que ARM esté creciendo hasta poder ser lo suficientemente autosuficiente, y eso parece no estar pasando. He estado esperando que esto pase por una década, y quién sabe cuándo llegue a suceder.

Podríamos estar en una situación donde uno termina con arquitecturas separadas para diferentes nichos: ARM para dispositivos eléctricos de consumidores y dispositivos integrados, y x86 para el mercado de PC/estación de trabajo/servidor. Con el soporte propio de arquitecturas que IBM tendrá para siempre (oigan, S/390 aún existe, y parece que Power también permanecerá), la realidad podría ser menos emocionante que una arquitectura Thunderdome ("dos arquitecturas entran, una arquitectura sale).

El mercado de computadoras ya no es tan loco y salvaje como solía ser. Sí, los teléfonos inteligentes de hecho tuvieron un impacto en este, pero el mercado de teléfonos inteligentes también se encuentra madurando.

¿Qué piensa de los proyectos que actualmente se encuentran en proceso para desarrollar kernels de sistema operativo en lenguajes como Rust (promocionado por contar con dispositivos de seguridad integrados que C no tiene)?

Ese no es para nada un fenómeno nuevo. Hemos estado con las personas que usaron Modula-2 o Ada, y debo decir que Rust se ve mucho mejor que cualquiera de esos dos desastres.

No estoy convencido sobre el uso de Rust para un kernel de sistema operativo (aparte del kernel, muchas cosas más entran en juego en la programación de un sistema), pero al mismo tiempo no cabe duda de que C tiene muchas limitaciones.

Para quien sea que desee construir su propio kernel desde cero, solo puedo desearle suerte. Es un proyecto inmenso, y no creo que uno resuelva ninguno de los problemas de kernel más difíciles con el lenguaje de programación que elija. Los problemas grandes tienden a relacionarse con el soporte del hardware (todos esos controladores, todos los detalles extraños sobre las distintas plataformas, todas las sutilezas en la administración de la memoria y la contabilidad de los recursos), y cualquiera que piense que la elección de un lenguaje simplifica bastante esas cosas probablemente termine decepcionándose mucho.

Para usted ¿cuál es la prioridad principal para llevar a cabo el desarrollo de un núcleo? ¿Respaldar nuevas funciones de hardware o CPU, mejorar el desempeño, reforzar la seguridad, permitir nuevos comportamientos de desarrolladores (como la tecnología de contenedores), o alguna otra cosa?

¿Yo personalmente? De hecho, suelo preocuparme más sobre temas del "flujo de desarrollo, no sobre asuntos inmediatos de código. Sí, aún me involucro en algunas áreas (principalmente en la capa VFS, pero ocasionalmente en la VM) donde me preocupo por temas particulares de desempeño, etc. pero siendo realista, hoy en día eso sería más como un pasatiempo alterno que mi trabajo principal.

Admito que aún encuentro las funciones de la nueva arquitectura CPU bastante interesantes - después de todo, es la razón por la cual inicié Linux en primer lugar, y aún es algo que sigo y amo ver cuando suceden las cosas nuevas e interesantes. Por ejemplo, estuve bastante emocionado por ver las funciones de memoria transaccional, aunque el alboroto parezca haber decaído bastante.

Pero siendo realista, en lo que realmente trabajo es en el proceso de desarrollo en sí y en mantener el kernel, un área que particularmente ya no pertenece al código. Leo correo electrónicos, extraigo solicitudes, delego cosas al desarrollador más indicado, e intento asegurar que se lleven a cabo los lanzamientos y que las personas puedan confiar en que el kernel y yo estaremos siempre disponibles. Y sí, responder los correos electrónicos de periodistas es algo que también considero como parte de mi trabajo.

Mi modelo principal con respecto al desarrollo del kernel es asegurar que todos los detalles sean correctos, que tengamos a las personas adecuadas trabajando en las cosas indicadas, y que no existan cosas innecesarias que obstaculicen el desarrollo. Si el proceso funciona bien, y a las personas involucradas les importa la calidad, en cierto sentido el resultado final se encargará de sí mismo.

Sí, eso es muy, muy diferente de lo que hice hace 25 años, obviamente. En ese entonces, yo mismo escribí el código, y escribir código era lo que hacía. Hoy en día, la mayoría del código que escribo es en realidad un conjunto de fragmentos en correo electrónicos, cuando se discute sobre algún asunto.

¿Qué cree usted que aún sería necesario hacer para mejorar los contenedores de Linux?

De hecho, estoy esperando a que el uso de éstos sea más extenso -actualmente son principalmente una cosa al lado del servidor que muchas de las compañías grandes utilizan para administrar sus cargas de trabajo, pero existe todo este rumor sobre utilizarlos para distribuciones de usuarios, y estoy convencido de que ese tipo de uso es en el que usted realmente termina encontrando muchos asuntos y puliendo el resultado.

Las personas de servidores están acostumbradas a trabajar en base a temas propios, que son muy particulares, con alguna peculiaridad que es específica para su carga. En contraste, una vez que termina usando contenedores en un ambiente más orientado al escritorio/estación de trabajo, donde la distribución de aplicaciones, etc. depende de éste, y todos son afectados, uno termina teniendo que acertar. Es por esto que aún soy un gran creyente de que el escritorio es una plataforma muy importante: Es este elemento de propósito general donde puede trabajar evadiendo alguna peculiaridad de alguna carga muy específica.

De hecho, espero que los contenedores saquen su cabeza fuera de la nube, por así decirlo, y que puedan estar en todos lados. No estoy completamente convencido de que eso vaya a suceder, pero obviamente hay muchas personas que están trabajando para lograrlo.

Hemos visto a Microsoft, Google y Apple impulsando nuevos lanzamientos de sistemas operativos de escritorio y móviles a un ritmo sin precedentes en estos últimos años. ¿Cuáles son sus observaciones respecto a los ciclos cada vez más frecuentes de lanzamiento de los sistemas operativos para escritorio y móviles?

Bueno, en el kernel nosotros obviamente hicimos nuestro propio gran lanzamiento de cambio de modelo hace aproximadamente 10 años, donde pasamos de un lanzamiento multianual (2.4 a 2.6) a un lanzamiento mucho más parecido a un despliegue (un nuevo lanzamiento cada mes o dos meses aproximadamente, y se trata más de "mejora continua en lugar de "la nueva gran función).

Francamente, habiendo atravesado ese gran cambio de mentalidad en el desarrollo de los kernels, realmente creo que es la única manera adecuada de hacer actualizaciones. Toda la noción de "grandes lanzamientos cada año o dos debería morir, en favor de las mejoras graduales constantes.

Por supuesto, muchas personas quieren el modelo de "gran lanzamiento revolucionario -a veces por razones de marketing, pero frecuentemente por razones técnicas (obstinadas), donde el gran lanzamiento revolucionario no solo es visto como una manera de hacer mejoras, sino también para romper el respaldo de las versiones o flujos de trabajo anteriores. Demasiadas personas parecen pensar que un "cambio radical es mejor y más interesante que una "mejora gradual.

Yo veo el "cambio radical como un fracaso. Si su nueva versión no puede hacer todo lo que hacía la anterior sin problemas, su nueva versión no es una mejora, es simplemente una molestia para los usuarios.

En el kernel, eso se muestra como nuestra regla número Nro.1: Nosotros no rompemos el espacio del usuario, y no hacemos regresiones. No importa que tan buena sea una nueva función o que tan astuto sea una parte del código -si rompe algo que solía funcionar, es una falla y necesita solucionarse.

Una vez que adopta ese tipo de modelo, el resultado lógico es un modelo de lanzamiento de despliegue, y no actualizaciones grandes que dejan atrás al código antiguo.

¿Cuál es su apreciación de las actualizaciones forzadas y preocupaciones de seguridad ligadas a Windows 10 y los movimientos de Apple hacia un sistema operativo de escritorio del tipo 'jardín amurallado'? ¿Considera que son catalizadores del cambio en dirección a un concepto fundamental de un sistema operativo de escritorio? ¿Cree que los sistemas operativos de escritorio de propósito general sobrevivirán de aquí a cinco o diez años?

Oh, definitivamente pienso que el sistema operativo de propósito general sobrevivirá y prosperará. Sí, muchas personas no necesitan ese tipo de ambiente de propósito general, por lo que existen buenas razones para ofrecer versiones reducidas que son (por ejemplo) más seguras simplemente porque son un poco más limitados y tiene reglas más estrictas. Muchas personas están felices con algo que solo haga búsquedas en la web y videos, y obviamente un ambiente limitado tiende a ser más simple y barato (y el hardware limitado -todos esos teléfonos y tabletas son excelentes en lo que hacen, pero uno necesita algo más orientado a la creación de contenido en vez de algo orientado al consumo de éste).

Pero eso no hace que las necesidades de propósito general desaparezcan. Significa que muchos contextos que solían requerir de PC completas -pero realmente no las necesitaban- estarán perfectamente felices con el ambiente reducido. No me sorprende que el mercado de PC haya estado paralizado y encogiéndose. Pero creo que es un balance natural nuevo, y no un declive fundamental.

¿Debido a los crecientes requisitos y cargas de trabajo disparejos para escritorios, móviles y servidores -especialmente en ambientes de servidor virtualizados como los contenedores- uno espera que llegue un momento en el que el kernel podría verse forzado a dirigirse en dos direcciones distintas debido a problemas de bloqueo arquitectónicos o quizás otras razones?

Solía pensar que eso era inevitable, pero ya no.

La causa de eso fue que cuando el SGI estaba (hace mucho -estamos hablando de aproximadamente 15 años) trabajando para realizar el crecimiento de Linux para sus sistemas grandes y hablando de ejecutar Linux en sistemas con cientos de nodos y miles de núcleos de CPU. Sentí que el esfuerzo requerido no tendría sentido para los casos normales donde uno solo tenía unas pocas CPU y SGI probablemente tendría que tener su propio conjunto de actualizaciones externas para sus necesidades muy especiales.

Estaba equivocado, muy equivocado.

No solo fuimos capaces de integrar las actualizaciones de SGI, sino que mejoramos el código al hacerlo -inclusive en los casos en los que no se relacionaban a SGI. Tuvimos que añadir cierta cantidad de abstracción y limpiar bastante nuestro manejo de los datos en cada CPU, pero el resultado fue una fuente base más robusta que estaba más limpia y mejor diseñada.

Actualmente tenemos un kernel bastante unificado que va desde teléfonos celulares hasta supercomputadoras, y me he convencido de que la unificación, de hecho, ha sido una de nuestras fortalezas más grandes: Nos obliga a hacer las cosas bien, y, de todas formas, las distintas necesidades para las plataformas diferentes tienden a tener una cantidad considerable de elementos en común.

Por ejemplo, el soporte para SMP provino de las necesidades del servidor, pero después se volvió común también en el escritorio, y ahora uno ya ni siquiera puede encontrar un teléfono celular sin CPU múltiples. El hecho de que hayamos tenido un buen soporte de núcleo de SMP resultó siendo importante hasta para las máquinas pequeñas, y dividir la base del código por razones de arquitectura (lo que pudo haber tenido sentido hace 15 años) podría haber sido un gran error.

Mucho del código de administración de la energía y las preocupaciones vinieron de las laptops y celulares, pero se usa con frecuencia en máquinas grandes también, donde resulta que el uso de energía sí importa. Aunque con frecuencia existen cosas que terminan siendo específicas para una plataforma, no siempre es obvio, y la mayoría de las veces esas cosas muy específicas se encuentran al final y los detalles pequeños pueden eliminarse (y compilados fuera para que no afecten siquiera a las plataformas que no los quieren o no los necesitan).

¿Qué tecnología, paquete o funcionalidad central dentro del kernel de Linux o distribuciones Linux ha durado mucho más tiempo del que usted pensó que duraría o debería haber durado?

Existe una serie de controladores que aún construimos y soportamos, pero sinceramente espero que nadie los utilice aún. Aún no estoy convencido de que sigan funcionando -¿acaso las personas aún siguen usando diskettes? Creo (y espero) que el controlador sea usado principalmente en ambientes virtualizados, no en hardware físico.

Pero en general, el código legacy no tiende a ser tan complicado de mantener, por eso lo conservamos.

¿Cuáles son nuestras esperanzas y miedos respecto a la IoT?

Espero que se calme al alboroto, y nos podamos concentrar en lo que realmente hace. ;)

Pero hablando en serio, espero que todos los problemas de interoperabilidad se solucionen, y espero que vayan a haber más dispositivos inteligentes pequeños que no coloquen todo en la nube. Ahora mismo, no solo las cosas dejan de funcionar si se pierde la conexión a Internet, sino que ya hemos tenido demasiados casos de dispositivos que simplemente dejaron de funcionar porque el servicio de nube fue apagado.

Sí, sí, se llama la Internet de las cosas, pero aun así... Algunas de esas cosas llegan innecesariamente lejos.

El año pasado se ha hablado sobre tecnologías de autoprotección para el kernel. ¿Cómo se vería eso?

Las más poderosas son las asistencias provenientes del hardware.

Todos saben a estas alturas que NX (la habilidad de marcar páginas como no ejecutables) atrapa cierta clase de ataques. Pero ahora también tenemos SMAP y SMEP (supervisor mode access/execute protection), que sella otra clase de agujeros, y hace que sea mucho más difícil engañar al kernel para que acceda (o ejecute) a un espacio de datos del usuario sin intención debido a una falla).

Particularmente, SMAP era algo que nosotros, las personas que utilizan el kernel de Linux, habíamos solicitado debido a que es bastante costoso hacerlo en software, pero el hardware ya tiene toda la información requerida en la TLB (translation lookaside buffer) cuando realiza el acceso. Sí, las nuevas funciones del CPU demoran mucho tiempo para llegar a los consumidores, y SMAP solo existe en los CPUs de Intel más recientes, pero representa un ejemplo de tecnologías que pueden protegerlo de toda una clase de ataques.

Existen otras herramientas que también utilizamos, éstas hacen uso de análisis estático y hacen que los compiladores generen código de revisión adicional. La última función puede ser bastante costosa (dependiendo de cuál revisión y qué carga operan las personas), pero para los casos costosos tendemos a tener opciones de configuración, para que uno pueda operar un kernel seguro, pero más lento y más grande, que realiza un autochecking.

El reto más grande es asegurarse de que los sistemas estén siempre actualizados de acuerdo al kernel más reciente. (¿Cuál es el punto de añadir funciones de seguridad si los servidores no están actualizándose de acuerdo al kernel más reciente? ¿Existen tendencias prometedoras hacia la automatización de las actualizaciones para los kernels, o se trata esencialmente de un problema de upstream (Red Hat, Ubuntu)?

Honestamente, hacer una actualización siempre implicará una demora. Nosotros hacemos cosas para que sea más fácil: Toda la regla de "nada de regresiones está ahí parcialmente para dejarle saber a las personas que realizar actualizaciones debería ser seguro siempre y no interrumpir lo que están haciendo, pero también existen personas que están trabajando para lograr actualizaciones en vivo para que usted pueda corregir fallas, en algunos casos, mientras está haciendo algo más.

Pero una de las razones para mucho del trabajo de refuerzo es lograr que realizar actualizaciones sea menos crítico, en ese caso.

Definitivamente, todavía no hemos llegado a ese punto. Y la seguridad "absoluta no existe, así que nada logrará ser un 100%. Pero las personas están trabajando para mejorar bastante las cosas en la práctica.

Frecuentemente, el mayor problema no es ni siquiera directamente técnico, sino sobre cómo las personas utilizan la tecnología. Puede ser bastante frustrante ver a las personas utilizar versiones básicas, viejas y probablemente muy inseguras debido a todas las razones equivocadas -porque el proveedor dificultó o hizo imposible realizar una actualización coherentemente. Quizás ellos utilizaron un pedazo de hardware con un controlador que no era de fuente abierta o donde el controlador no era upstream, sino alguna abominación del proveedor que no es capaz de recibir actualizaciones. En ese tipo de situaciones, realizar un upgrade resulta mucho más difícil. Eso solía ser un problema en el espacio integrado -está mejorando, pero aún es un problema.

La "incapacidad para hacer upgrades y sus problemas conocidos de vacíos en la seguridad son algunas de las pesadillas que las personas tienen respecto a la IoT. Algunos de esos dispositivos realmente no cuentan con un modelo de upgrade, y al proveedor prácticamente no le importa. Nosotros solíamos ver eso en muchos routers hogareños -y routers empresariales también-, pero con la IoT obviamente se está expandiendo a muchos equipos en su hogar.

Paul Venezia, InfoWorld (EE.UU.)