Dave Cutler explica Windows [video]
(youtube.com)- Dave Cutler repasa, a partir de su experiencia que va de RSX-11, VMS y Windows NT hasta Azure y Xbox, el contexto de diseño de Windows NT y la cultura de desarrollo de Microsoft
- Windows NT tuvo desde el inicio el objetivo de ser un sistema operativo portable y admitir múltiples entornos de ejecución; cuando Windows 3.1 vendió 16 millones de copias en 6 meses, Windows pasó a ser el entorno central en lugar de OS/2
- Las primeras versiones de NT trabajaron con varias arquitecturas como i860, MIPS, x86, Alpha y PowerPC, además de HAL, el administrador de objetos y la estructura de kernel/drivers; buena parte de la estructura central sigue presente en Windows 11
- VMS apuntaba a tener 0 bugs conocidos al momento del lanzamiento, y el equipo de NT mantuvo la cohesión organizacional con Friday WHIM, pero en NT, Cairo, Longhorn y la respuesta de seguridad de XP, los plazos, la calidad y la bifurcación del codebase fueron una carga importante
- Cutler considera que corregir bugs, hacer pruebas, asegurar la calidad y tener la disciplina de no incluir funciones innecesarias son actitudes clave de un buen equipo de software
Trayectoria en sistemas operativos antes de Windows NT
- Dave Cutler conoció los sistemas en tiempo real y las simulaciones por computadora en DuPont, y terminó interesándose más por la computadora en sí que por las herramientas para resolver problemas
- En un proyecto para simular con GPSS 3 el proceso de fabricación de espuma de Scott Paper, se enfrentó a errores en tarjetas y depuración
- Para reducir errores escribió un programa en Fortran y luego aprendió incluso assembler de IBM 7044, ampliando su interés por el funcionamiento interno de las computadoras
- En el grupo de sistemas en tiempo real de DuPont escribió un programa para analizar automáticamente datos de ensayos de tracción de Instron
- El programa de captura de datos funcionaba en tiempo real y leía datos en intervalos de 1 milisegundo o 100 milisegundos
- Más tarde, al encargarse del sistema operativo Exec II de Univac 1107, entró de lleno en el desarrollo de sistemas operativos
- Todos los días a las 5 p. m. hacían salir al operador y durante 2 horas ejecutaban código experimental y pruebas
- En un entorno casi sin depuradores, depuraban con switches e instrucciones halt
Época en DEC: RSX, VMS, compiladores y PRISM
- En Digital Equipment Corporation fue contratado inicialmente para OS/45, pero pronto pasó a trabajar en RSX-11C
- En ese momento, el espacio de direcciones de 16 bits del PDP-11 le parecía a Cutler una gran limitación
- Evalúa a RSX-11C como un sistema pequeño y con funciones limitadas incluso para los estándares de la época
- El desarrollo de VMS se arrancó aprovechando el hardware VAX y una capa de ejecución compatible con PDP-11
- VAX tenía un modo PDP-11, y una capa llamada Application Migration Executive ejecutaba utilidades de RSX-11M
- También se reimplementó el sistema de archivos Files-11 en VMS para mantener compatibilidad
- En las primeras etapas de desarrollo, tareas centrales como scheduling y administración de memoria se realizaron en un emulador de hardware
- VMS usó el autohospedaje como medio para asegurar la calidad
- Cuando Proto 3 empezó a ejecutarse con suficiente estabilidad, el equipo de desarrollo trabajó directamente sobre ese sistema
- Si el sistema generaba un bug check, varias personas iban a la máquina, buscaban la causa con el depurador, corregían y volvían a arrancar
- Recuerda que VMS salió con “0 bugs conocidos”
- Eso no significa que “no hubiera bugs”, sino que intentaron corregir todos los bugs que conocían al momento del lanzamiento
- Incluso a último momento corrigieron una race condition en el driver de disco
- Después de VMS también participó en el compilador de PL/I, el backend del compilador de C, el generador de código, optimización y asignación de registros
- El frontend de PL/I se compró a una empresa de Boston, y el backend se desarrolló en VAX
- Parte del trabajo de frontend se hizo en Multics del MIT, trasladando los datos en cintas
- En DEC West participó en un sistema en tiempo real llamado Velon y en el proyecto MicroVAX
- Velon era un sistema que experimentaba con ideas como drivers en modo usuario, estructura orientada a mensajes, multithreading y multiprocesadores
- En MicroVAX 1, Cutler escribió todo el microcódigo
- El proyecto PRISM fue el intento de DEC de crear una arquitectura RISC, y al día siguiente de su cancelación Cutler decidió dejar la compañía
- PRISM tenía arquitecturas de 32 y 64 bits, y también estaba en marcha un ambicioso sistema de software llamado Micah
- Tras la cancelación de PRISM intentó fundar una empresa de servidores, pero el rumbo cambió al entrar en contacto con Microsoft
Incorporación a Microsoft y diseño de Windows NT
- Su incorporación a Microsoft no quedó asegurada aun después de hablar con Bill Gates, pero se decidió rápidamente después de desayunar con Steve Ballmer en Denny’s
- Cutler considera que Ballmer fue la figura clave que lo convenció de sumarse a Microsoft
- El objetivo inicial de NT era ser un sistema operativo portable y soportar múltiples entornos de ejecución
- El entorno objetivo de la época era OS/2, y POSIX también era un candidato importante
- La idea empezó con un núcleo del sistema que ofreciera servicios básicos y varios entornos montados encima
- El éxito de Windows 3.1 fue lo que convirtió a Windows en el entorno central de NT
- Windows 3.1 vendió 16 millones de copias en 6 meses, y Bill Gates determinó que el entorno principal del nuevo sistema sería Windows
- Aunque el desarrollo de NT también se hacía sobre OS/2, el equipo quería pasar pronto a autohospedarse en NT
- El nombre NT significa “New Technology”
- Puede haber existido una conexión difusa entre el nombre en clave N10 del i860 y NT, pero Cutler entiende NT como New Technology
- El área de marketing se opuso porque un nombre como “nueva tecnología” podía desalentar compras, pero Cutler insistió con el nombre NT
- La primera versión de NT soportaba varias arquitecturas de CPU
- Se mencionan x86, MIPS R3000/R4000 y Alpha
- PowerPC llegó en la época de NT 3.5 o Daytona, y Cutler evalúa que el build y la competitividad de hardware de PowerPC no eran buenos
- El HAL de NT originalmente era más cercano a una capa de abstracción de vendors que a una capa de abstracción de hardware
- Al principio se componía como una DLL separada para que los vendors pudieran proveer el HAL
- Cutler cree que más adelante habría sido mejor compilar el HAL como una parte del sistema operativo
- El kernel de NT y el HAL no tenían mucho assembler
- Algunas operaciones frecuentes necesarias por rendimiento requerían assembler o intrinsics
- En x64 optaron por usar intrinsics en lugar de inline assembly
Cultura de desarrollo de NT, Cairo, Longhorn y seguridad de XP
- El equipo de NT organizaba cada viernes un WHIM para cohesionar una organización que crecía rápidamente
- WHIM era la sigla de Weekly Integration Meeting
- Al principio, los managers compraban cerveza y papas fritas en Safeway y lo hacían en el laboratorio de hardware; más tarde se expandió a espacios más grandes y catering
- Cutler considera que no es cierto que el desarrollo de NT solo exprimiera continuamente a la gente, y que intentaban crear una oportunidad semanal para distenderse
- Después de NT 3.5, avanzaron en paralelo la incorporación de la UI de Windows 95 a NT y el proyecto Cairo
- Tuckwila se mantenía como una especie de NT 4.0 de respaldo, y en los builds diarios Tuckwila salía estable, mientras Cairo se rompía con frecuencia
- Las funciones de Cairo se fueron retirando gradualmente, y los principales resultados portados que Cutler recuerda son software de servidor de archivos y Kerberos
- NT 4.0 quedó como una versión muy popular, y Cutler aún llegó a conocer a personas que usaban NT 4.0
- El cronograma de NT 3.1 tomó más tiempo que VMS
- Según dice, VMS fue creado en 2 años por un equipo muy talentoso de unas 20 personas
- NT tenía que hacer más cosas, y el alcance creció al abandonar i860 y agregar varias arquitecturas como MIPS, x86 y Alpha
- En el proceso que llevó a Longhorn y Vista, la separación del codebase se convirtió en un gran problema
- Después de Windows 2000, los codebases de servidor y workstation se separaron; mientras el lado servidor corregía muchos problemas de seguridad, el lado consumidor se volvió inestable para compilar y ejecutar
- XP fue un gran éxito, pero tenía muchos bugs; después, al crecer los problemas de seguridad, se dedicó mucho esfuerzo a corregir bugs de XP
- El grupo de Cutler corrigió unos 5.000 bugs de seguridad relacionados con XP
- La extensión x64 de AMD fue un punto de inflexión importante dentro de Microsoft
- AMD propuso una idea de extensión de 64 bits menos invasiva, capaz de ejecutar aplicaciones de 32 bits con rapidez
- Cutler decidió crear workstations y servidores de 64 bits sobre la base del codebase de servidor, y no era un proyecto aprobado oficialmente por la compañía desde el inicio
- Cuando llegaron los sistemas AMD, arrancaron por primera vez desde CD, y el sistema de 64 bits arrancó y se ejecutó de inmediato
- microsoft.com probó servidores de 64 bits durante aproximadamente una semana y luego migró; fueron evaluados como mucho más estables que los sistemas de 32 bits
- Longhorn finalmente se trasladó al codebase x64, y ese codebase continúa hasta hoy
Estructura interna de Windows y código que permanece hasta hoy
- En Windows 11 todavía queda mucha estructura y funcionalidad central de la época de NT 3.5
- Continúan elementos centrales como código del kernel, estructura de administración de memoria, estructura de procesos y administrador de objetos
- Aunque la proporción de código original dentro del total sigue disminuyendo, gran parte de las estructuras centrales que cumplen las mismas funciones permanece
- Cutler señala al administrador de objetos de NT como una razón importante de una buena base de código
- A diferencia del enfoque de Unix de “todo es un archivo”, en NT se puede crear un nuevo descriptor de tipo de objeto e integrarlo al administrador de objetos para agregar nuevos objetos del sistema operativo
- Los objetos pueden ofrecer funciones como sincronización y control de acceso
- La handle table era una parte importante para el rendimiento, por lo que fue reescrita varias veces
- La traducción de handles era un problema real de rendimiento
- Como ejemplo, menciona que en su sistema de trabajo hay unos 60 procesos, cientos de threads y 150.000 handles abiertos
- El aumento de tamaño del Task Manager se menciona como ejemplo de expansión del código
- El Task Manager original compilaba a 85 KB, pero ahora pesa 4 MB
- Hoy muestra más información como CPU, red y disco, pero Cutler no cree que las funciones hayan crecido en la misma proporción que el tamaño
- La decisión de mover los drivers gráficos de modo usuario a modo kernel fue necesaria por rendimiento, pero generó dolores de crecimiento
- Cutler inicialmente se oponía a moverlos a modo kernel
- El modo usuario y el modo kernel tienen modelos de sincronización distintos, así que no era un simple traslado de código; las estructuras de datos y primitives de 16 bits también eran una carga
- Más adelante la confiabilidad mejoró mucho, aunque durante un tiempo hubo muchos problemas con drivers gráficos de vendors
Azure, Xbox, xCloud
- Después de enviar los sistemas x64, Cutler se frustró por el problema de fcib y dijo que renunciaría a Microsoft; por sugerencia de Steve Ballmer, se tomó vacaciones y volvió en noviembre de 2005
- fcib significa checked-in binary, y dificultaba los ports porque había grupos que hacían check-in de binarios en lugar de código fuente
- Luego participó en el proyecto inicial de Azure
- Ray Ozzie impulsó el proyecto al ver que varios servicios basados en la nube no tenían una infraestructura común
- El Azure inicial apuntaba a infraestructura de plataforma como despliegue de aplicaciones, control de configuración, gestión de versiones, reinicio, facturación y un sistema de archivos en la nube
- Explica que lo que ofrecía AWS estaba centrado en infraestructura, mientras Microsoft inicialmente intentaba vender servicios de plataforma
- El hipervisor inicial de Azure se creó sobre tecnología adquirida con Connectix
- Connectix tenía productos Virtual PC y Virtual Server, y el desarrollo del hipervisor también estaba en una etapa inicial
- Más tarde, el hipervisor de Xbox provino del hipervisor Red Dog de Azure
- Xbox opera con una estructura de tres VM
- El host system posee todos los dispositivos y actúa como traffic cop para la comunicación entre VM
- La presentation VM se encarga del administrador de ventanas y el sistema de visualización, y se ejecuta continuamente
- La game VM se inicia y detiene para cada juego, y el juego se empaqueta junto con el OS
- La estructura en la que el juego se empaqueta junto con el OS favorece la retrocompatibilidad
- El desarrollador del juego empaqueta el juego junto con el OS del GDK, y al ejecutarlo se inicia también esa VM
- Así se evita que cambios en el sistema operativo rompan juegos existentes
- Sin embargo, cuando una función debe incorporarse en juegos existentes, se necesitan rodeos como un universal game OS
- El pause/resume de Xbox funciona guardando y restaurando VM
- La carga de juegos implica datos de varios gigabytes y tarda bastante
- pause/resume es una función que guarda el estado de la VM y lo restaura más tarde
- Como trabajo actual se mencionan una VM Linux y un stack gráfico que aprovechan el tiempo ocioso de las consolas xCloud
- xCloud consiste en reempaquetar consolas Xbox en racks, colocarlas en datacenters y ofrecer acceso remoto
- La consola es single tenant, por lo que la usa una sola persona a la vez y se genera tiempo ocioso
- Para un plan de ejecutar workloads de machine learning exclusivos de Microsoft en los períodos sin uso, están trabajando en una VM Linux, el hipervisor de Xbox y el stack gráfico
Calidad, gestión de equipos y filosofía de desarrollo
- Cutler aplica también a los equipos de software la frase “la gente exitosa hace lo que la gente que fracasa se niega a hacer”
- Ve como problemas la actitud de escribir código y no probarlo, irse a las 5 p. m. cuando aún queda cronograma disponible, o no querer corregir los propios bugs
- Considera importante la actitud de hacer personalmente lo necesario para lograr el éxito
- Valora mucho al “thinker-doer”
- Citando a Brooks, dice que hay muchas personas que solo piensan pero pocas que realmente ejecutan, y todavía menos que hagan ambas cosas
- Cree que también los arquitectos deben producir resultados reales que satisfagan objetivos y restricciones
- Quería poner en la pared del laboratorio de la University of Washington la frase “si no lo metes, no tendrás que sacarlo”
- La usa para enfatizar la disciplina de no incluir funciones innecesarias
- En los primeros entornos de desarrollo las herramientas de depuración eran pobres, por lo que era importante reducir errores desde el principio
- En el pasado, a veces incluso había que usar logic analyzers u oscilloscopes
- Considera que las herramientas actuales tienen muchas funciones para reducir pequeños errores, pero que la presión por la calidad es distinta a la de antes
- Cree que el multitasking es posible, pero que la máxima productividad proviene de concentrarse en una sola tarea
- Esto se debe a que el context switch toma tiempo
- Aun así, explica que sí cambia de tarea para ayudar a otros con problemas en los que están bloqueados o para corregir bugs
1 comentarios
Opiniones de Hacker News
El entrevistador, Dave Plummer, también es una persona muy interesante por sí mismo. Me gustaron especialmente sus videos de programación retro, como https://www.youtube.com/watch?v=JlZe2JwrJqM y https://www.youtube.com/watch?v=b0zxIfJJLAY
Los videos también son entretenidos, y la música de fondo y las luces RGB les dan un ambiente navideño. También hicieron que Microsoft se viera de una forma completamente distinta a la imagen a la que yo estaba acostumbrado; habla con calidez de su trabajo, sus colegas y Microsoft, aun reconociendo las rarezas de Redmond
Eso sí, al ver este canal parece que el algoritmo de YouTube activa algo y el feed de recomendaciones se llena de videos sobre TDAH. Probablemente sea por los videos relacionados con autismo y TDAH, pero uno pensaría que YouTube debería ser lo bastante inteligente como para darse cuenta de que lo único que vi fueron videos de programación e historia de Microsoft
Aunque no me gusta decir esto, hay que tomar con bastante reserva lo que dice sobre temas fuera de Microsoft/Windows. Sobre todo después del comentario de abajo [1]
Lo de forzar recientemente a desactivar los bloqueadores de anuncios también fue revelador. Los anuncios de YouTube son realmente de lo peor, y da vergüenza pensar que personas reales reaccionan a eso. Parece que YouTube ya renunció incluso a fingir que intenta ofrecer una buena experiencia de usuario
Aun así, vale la pena revolver un poco el barro para ver cosas excelentes como esta entrevista a Dave Cutler
No es broma, y decir “la mitad” es bastante preciso. Algo se rompió, o YouTube le enchufó un modelo grande de lenguaje a su motor de recomendaciones
Me gustó más verlo hablar de forma improvisada que en videos bien editados
Después de ese único video, mis recomendaciones se llenaron de historias sobre cáncer, personas en sus últimos días y todo tipo de enfermedades. Ese video no tenía nada que ver con el contenido habitual de esa persona, y no vi ninguno de esos videos recomendados, pero siguieron apareciendo
Todavía no vi este video, pero leí Showstopper[1] hace unos años, así que tengo expectativas
Algo que se me quedó muy grabado, sobre todo cuando a mis veintipocos pensaba que siempre había que trabajar, fue la parte en que Dave siempre se tomaba sus vacaciones a tiempo, sin discutir, sí o sí
Puede que a uno no le guste Microsoft, pero probablemente fue la primera vez que vi de verdad a alguien muy competente y calificado que no vivía siendo exprimido las 24 horas
Incluso escribirlo así todavía se siente raro, pero venía de una mentalidad heredada de la cultura rural y del comercio minorista, de que “mientras más sufres, más virtuoso eres”
Aún hoy me cuesta descansar bien, y es fácil postergarlo con la excusa de que X o Y es más importante. Pero recordar la perspectiva de Dave es un buen reminder de que descansar y hacer bien X no son opciones mutuamente excluyentes
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
“Acuérdate del día de reposo para santificarlo… Seis días trabajarás y harás toda tu obra, mas el séptimo día es reposo para Jehová tu Dios…”
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
Mientras más trabajan los empleados “con la nariz pegada a la piedra de afilar” y “rompiéndose la espalda”, más suben las ganancias de la empresa, sin que haga falta pagarles más. Si su salud se deteriora lo suficiente como para que ya no puedan trabajar, simplemente se los reemplaza
Perdón si suena tosco, es una respuesta escrita tarde en la noche, pero creo que la gente de aquí ya lo entiende intuitivamente
Luego me llegó el burnout, y ahora veo que descansar y respetar jornadas de 8 horas —salvo emergencias reales— no solo es una responsabilidad personal, sino también profesional. Reduce el riesgo de burnout, y el burnout es literalmente malo para todos
Leí en alguna parte que, hacia el final del desarrollo de WinNT 3.1, alguien hizo un protector de pantalla que mostraba una pantalla azul. Tal vez fue en Usenet
Hasta ese momento nunca había hecho un protector de pantalla, pero por un bug en un driver de red interno de Microsoft podía hacer que mi máquina de desarrollo con WinNT mostrara una pantalla azul de forma confiable
Así que leí la documentación para escribir protectores de pantalla de Windows, anoté los valores que aparecían en mi pantalla azul y armé de cualquier manera mi primer y último protector de pantalla para Windows
Por diversión, mandé un correo al grupo de Windows NT avisando lo que había hecho, y unas semanas después el grupo de builds de NT decidió gastarle una broma a Dave Cutler
Instalaron mi protector de pantalla de pantalla azul en uno de los servidores de build, desconectaron también el mouse y el teclado, y esperaron
Dave Cutler llegó para ver el estado del build más reciente de NT, encendió el monitor y vio la pantalla azul. Movió el mouse, pero no pasó nada; tecleó, y tampoco pasó nada
Entonces ocurrió lo inesperado: extendió la mano y apretó el botón de encendido del servidor de build para reiniciarlo. NOOOOOOOOOOOOOOOOOOOOO
Nunca supe cuáles fueron las repercusiones o consecuencias de esa broma. Un gran poder conlleva una gran responsabilidad
Yo también lo instalé, y varios compañeros sentados cerca hicieron lo mismo
El CTO pasó por ahí por una reunión temprano en la mañana y, al ver eso en todas las pantallas, entró en un leve pánico pensando que era la propagación de un virus o un bug de software
Recomiendo también el libro que alguien recomendó por aquí hace unas semanas, “Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft”
Todavía lo estoy leyendo, pero es muy entretenido, y me hace pensar que me habría gustado participar en esa historia. En especial la parte de hacer dogfooding de un sistema operativo completamente nuevo. Aunque fue unos años antes de mi época
Gracias a ese libro soné como si supiera mucho más de lo que realmente sabía, y estaba mucho más entusiasmado con todo ese campo que unos días antes
Me hicieron una oferta, pero al final no tomé ese trabajo
Relacionado, también está esto: https://blog.codinghorror.com/showstopper/
Una parte que me pareció interesante fue que el hipervisor de Xbox no fue creado por el lado de escritorio, sino que está basado en Azure, y que los juegos de Xbox, en lugar de depender de un único sistema operativo sobre el dispositivo, se empaquetan junto con el sistema operativo, algo un poco más cercano a un contenedor.
Dave dijo que también está trabajando en hacer que dispositivos inactivos de Xbox Cloud Gaming ejecuten tareas de machine learning. Nunca se me había ocurrido que existiera una conexión arquitectónica así entre Azure y Xbox.
Por ejemplo, el ejecutable del juego está en realidad cifrado en el disco del juego, y hasta dumpear el binario real en ejecución es casi imposible. La RAM también está cifrada.
Además, una de las razones por las que los TPM modernos terminaron dentro del CPU fue evitar que la gente esnifara el bus del TPM, como hicieron con la Xbox.
Trabajé en el equipo del kernel de Windows, y mi historia favorita sobre DC es que odiaba tanto la arquitectura Itanium que básicamente hizo posible x64.
Trabajando con AMD, lo impulsó prácticamente él mismo, escribiendo código sin parar desde su oficina de esquina.
La idea era que “si agrupas varias instrucciones, a veces de longitud variable en bits, en una palabra, y dejas que quien escribe el compilador encuentre el agrupamiento óptimo de instrucciones, la implementación se simplifica y puede ser más rápida”; pero si el compilador no encuentra ese agrupamiento óptimo, termina siendo más lenta que un diseño tradicional como x86.
Alguien muy arriba dentro de Intel de verdad debía amar esta idea. A lo largo de toda la historia de Intel como gran fabricante de microprocesadores, lo intentaron tres veces y fracasaron tres veces.
En ese momento AMD64 no se veía como una buena idea, sino como “más de lo mismo”. Aun así, fue bueno que Dave ayudara a barrer la mezcolanza que en la práctica había matado la revolución RISC.
Ojalá algún día yo también pueda crear algo así de impresionante en mi tiempo libre.
Lamentablemente para Microsoft, ese botín se lo llevó Linux sobre x86-64.
Uno de los momentos más decisivos de mi carrera en ingeniería de software fue, hace 6 o 7 años, leer el código fuente filtrado de NT junto con Showstopper[1].
La filtración de NT era especialmente fascinante porque incluía todo el historial de autores, así que se podía ver exactamente en qué archivos había trabajado Dave Cutler. El libro también cubre en detalle cosas como cómo surgieron las secciones paginables en los módulos del kernel, lo cual ya de por sí es interesante.
En el libro hay una escena en la que Cutler llega y destripa una rutina en ensamblador, y en el código fuente real se puede ver exactamente cuál era esa rutina.
El código de Cutler era C realmente hermoso, y seguramente todavía lo es. Influyó mucho en la forma en que escribo C al estilo NT.
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
La entrevista de historia oral a David Cutler del Computer History Museum también es muy buena.
Parte 1: https://youtu.be/29RkHH-psrY
Parte 2: https://youtu.be/SVgSLud50ss
Vi algunos fragmentos de la nueva entrevista, pero hasta ahora no estoy seguro de haber escuchado algo nuevo.
Si repasamos lo que dijeron los dos Dave, se presta una atención enorme a terminar y lanzar, pero casi no se habla de planificación a largo plazo ni de una estrategia de seguridad real.
Todo gira en torno a sacar salchichas de la picadora bajo presión comercial y reducir las fallas a un nivel aceptable.
No sorprende que la situación de toda la industria no mejore ni tome el rumbo correcto. Pensé que algún día llegaríamos a la seguridad basada en capabilities, pero ahora parece que quedaremos atrapados para siempre en su primo casi inútil: las banderas de permisos de las aplicaciones.
Me preocupa el futuro.
Basta con tener un buen trimestre o unos buenos años para justificar el ascenso de VP a SVP, o de SVP a CEO. Nadie culpa ni castiga a alguien que, tres años después, ya se mudó a otro rol por las decisiones cortoplacistas que tomó en su puesto anterior.
Eso no quiere decir que Cutler sea ese tipo de ejecutivo. Pero claramente recibió presión desde arriba para lanzar y para mantener el flujo de ingresos. Como dice al comienzo de la entrevista, realmente odia enviar bugs, está muy decepcionado con la calidad de los ingenieros de software de la industria y también detesta que los gerentes de programa/proyecto traten todos los bugs como si fueran casos límite raros. Estoy de acuerdo con las tres cosas.
La mayoría de los bugs que reporto también se tratan como “casos límite”, aunque yo me topo con ese problema todos los días y en la base de datos hay varios issues duplicados, o mi bug termina marcado como duplicado de un reporte anterior.
He pasado décadas en esta industria, todas en Big Tech, y todavía no he visto una empresa que no termine cediendo ante el mismo tipo de presiones, aunque los ingenieros y los gerentes de primera línea insistan en corregir bugs antes del lanzamiento y pidan actualizaciones de corrección de bugs más frecuentes.
Era un gran argumento de venta, pero a la mayoría de los usuarios no les decía mucho. De hecho, muchos sentían “¿para qué necesito esto?”, y hacía que no pareciera un sistema operativo para el “usuario común”.
Los conceptos de seguridad de comienzos de los años 90 —qué hace que algo sea seguro y para quién es relevante, y en qué medida— no coinciden con las expectativas actuales ni con el estado del arte.
Puede que lleve un tiempo hacerlo bien. Mientras tanto, espero que no gane una alternativa regresiva basada en un único runtime, a medio cocinar y que refuerce el statu quo.
[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
Este quizá sea el mayor producto económico que el software nos ha “aportado”: contratos vinculantes del tipo “tomaremos tu dinero, pero no prometemos nada, ¡ingenuo!”.
En cambio, si sales segundo al mercado, te castigan.
Tengo ganas de escuchar todo esto.
Más allá de lo que uno sienta por él o por la empresa en la que trabaja, Cutler fue un ingeniero de software muy influyente por su trabajo en OpenVMS y Windows NT. Creo que no se habla de él tan seguido como de gente de Bell Labs, Stallman, Linus o Stroustrup.