Dave Cutler explica o Windows [vídeo]
(youtube.com)- Dave Cutler relembra o contexto de projeto do Windows NT e a cultura de desenvolvimento da Microsoft com base em sua experiência que vai de RSX-11, VMS e Windows NT até Azure e Xbox
- O Windows NT foi concebido desde o início com o objetivo de ser um sistema operacional portável e de oferecer suporte a vários ambientes de execução, e o Windows acabou se tornando o ambiente principal em vez do OS/2 depois que o Windows 3.1 vendeu 16 milhões de cópias em 6 meses
- O NT inicial lidava com várias arquiteturas como i860, MIPS, x86, Alpha e PowerPC, além de HAL, gerenciador de objetos e a estrutura de kernel/drivers, e uma parte considerável dessas estruturas centrais ainda permanece no Windows 11
- No lançamento do VMS, a meta era ter 0 bugs conhecidos, e a equipe do NT mantinha a coesão organizacional com o Friday WHIM, mas cronograma, qualidade e a divisão do codebase se tornaram grandes pesos em NT, Cairo, Longhorn e na resposta de segurança do XP
- Cutler vê correção de bugs, testes, garantia de qualidade e a disciplina de não adicionar recursos desnecessários como atitudes centrais de uma boa equipe de software
Carreira em sistemas operacionais antes do Windows NT
- Dave Cutler teve contato com sistemas em tempo real e simulação computacional na DuPont e passou a se interessar mais pelo próprio computador do que pelas ferramentas de resolução de problemas
- Em um projeto que simulava o processo de fabricação de formulários da Scott Paper com GPSS 3, enfrentou erros de cartão e depuração
- Para reduzir erros, escreveu programas em Fortran e depois aprendeu até assembly do IBM 7044, ampliando seu interesse pelo funcionamento interno dos computadores
- No grupo de sistemas em tempo real da DuPont, escreveu programas para analisar automaticamente dados de ensaios de tração da Instron
- O programa de coleta de dados funcionava em tempo real e lia os dados em intervalos de 1 milissegundo ou 100 milissegundos
- Depois, ao assumir trabalho no sistema operacional Exec II do Univac 1107, entrou de vez no desenvolvimento de sistemas operacionais
- Todos os dias, às 17h, mandava o operador embora e rodava código experimental e testes por duas horas
- Em um ambiente quase sem depurador, fazia debugging com switches e a instrução
halt
Período na DEC: RSX, VMS, compiladores e PRISM
- Na Digital Equipment Corporation, foi contratado primeiro para o OS/45, mas logo passou a trabalhar no RSX-11C
- Na visão de Cutler, o espaço de endereçamento de 16 bits do PDP-11 era uma grande limitação
- Ele avaliava o RSX-11C como um sistema pequeno e limitado mesmo para os padrões da época
- O desenvolvimento do VMS foi bootstrapado usando o hardware VAX e uma camada de execução compatível com o PDP-11
- O VAX tinha modo PDP-11, e uma camada chamada Application Migration Executive executava utilitários do RSX-11M
- O sistema de arquivos Files-11 também foi reimplementado no VMS para manter compatibilidade
- No início do desenvolvimento, tarefas centrais como escalonamento e gerenciamento de memória foram feitas em um emulador de hardware
- O VMS usava self-hosting como forma de garantir qualidade
- Quando o Proto 3 ficou estável o suficiente, a própria equipe passou a trabalhar em cima desse sistema
- Quando o sistema gerava um bug check, algumas pessoas iam até a máquina, encontravam a causa no depurador, corrigiam e reinicializavam
- Ele relembra que o VMS foi lançado com “0 bugs conhecidos”
- Isso não significava “sem bugs”, mas sim que tentavam corrigir todos os bugs conhecidos antes do lançamento
- Até no último momento corrigiram uma race condition no driver de disco
- Depois do VMS, também trabalhou com compilador PL/I, backend de compilador C, gerador de código, otimização e alocação de registradores
- O frontend de PL/I foi comprado de uma empresa de Boston, e o backend foi desenvolvido no VAX
- Parte do trabalho de frontend foi feita no Multics do MIT, com os dados sendo transferidos por fita
- Na DEC West, participou do sistema em tempo real Velon e do projeto MicroVAX
- Velon era um sistema que experimentava ideias como drivers em modo usuário, arquitetura orientada a mensagens, multithreading e multiprocessamento
- No MicroVAX 1, Cutler escreveu todo o microcódigo
- O projeto PRISM era a tentativa da DEC de criar uma arquitetura RISC, e no dia seguinte ao cancelamento Cutler decidiu sair da empresa
- O PRISM tinha versões de arquitetura de 32 e 64 bits, e um sistema de software ambicioso chamado Micah também estava em andamento
- Após o cancelamento do PRISM, ele tentou fundar uma empresa de servidores, mas mudou de direção ao entrar em contato com a Microsoft
Entrada na Microsoft e projeto do Windows NT
- Entrar na Microsoft não era algo certo nem depois de conversar com Bill Gates, mas a decisão veio rapidamente após um café da manhã com Steve Ballmer no Denny’s
- Cutler considera Ballmer a pessoa-chave para convencê-lo a ir para a Microsoft
- Os objetivos iniciais do NT eram um sistema operacional portável e suporte a vários ambientes de execução
- Na época, o ambiente-alvo era o OS/2, e POSIX também era um candidato importante
- A ideia começou com um núcleo do sistema fornecendo serviços básicos, sobre o qual vários ambientes seriam executados
- O motivo de o Windows ter se tornado o ambiente central do NT foi o sucesso do Windows 3.1
- O Windows 3.1 vendeu 16 milhões de cópias em 6 meses, e Bill Gates concluiu que o Windows seria o ambiente principal do novo sistema
- O desenvolvimento do NT chegou a acontecer sobre o OS/2, mas a equipe queria migrar o quanto antes para self-hosting no próprio NT
- O nome NT significa “New Technology”
- Pode até ter havido uma ligação vaga entre o codinome N10 do i860 e NT, mas Cutler entende NT como New Technology
- O marketing se opunha ao nome por achar que “nova tecnologia” poderia afastar compradores, mas Cutler insistiu em NT
- A primeira versão do NT suportava várias arquiteturas de CPU
- São citados x86, MIPS R3000/R4000 e Alpha
- O PowerPC entrou na era do NT 3.5 ou Daytona, e Cutler avaliava mal tanto os builds para PowerPC quanto a competitividade do hardware
- O HAL do NT originalmente era mais próximo de uma camada de abstração de fornecedor do que apenas uma camada de abstração de hardware
- No início, ele era composto como uma DLL separada para que o fornecedor pudesse fornecer seu HAL
- Mais tarde, Cutler passou a achar que teria sido melhor compilar o HAL como parte do próprio sistema operacional
- Havia pouco assembly no kernel e no HAL do NT
- Algumas operações frequentes que exigiam desempenho precisavam de assembly ou intrinsics
- No x64, a direção escolhida foi usar intrinsics em vez de inline assembly
Cultura de desenvolvimento do NT, Cairo, Longhorn e segurança do XP
- Para manter unido um grupo que crescia rapidamente, a equipe do NT realizava toda sexta-feira o WHIM
- WHIM era a sigla de Weekly Integration Meeting
- No começo, gerentes compravam cerveja e salgadinhos no Safeway e faziam o encontro no laboratório de hardware; depois, o evento cresceu para espaços maiores com catering
- Cutler diz que é falsa a imagem de que o desenvolvimento do NT era apenas exploração constante das pessoas, e que eles tentavam criar um momento semanal para relaxar
- Depois do NT 3.5, correram em paralelo o esforço de levar a interface do Windows 95 para o NT e o projeto Cairo
- Tuckwila era mantido como uma espécie de NT 4.0 de backup; nos builds diários, Tuckwila saía estável, enquanto Cairo quebrava com frequência
- Os recursos do Cairo foram sendo retirados aos poucos, e os principais resultados portados de que Cutler se lembra são o software de servidor de arquivos e o Kerberos
- O NT 4.0 permaneceu como uma versão muito popular, e Cutler diz já ter encontrado gente que ainda usa NT 4.0
- O cronograma do NT 3.1 levou mais tempo que o do VMS
- Segundo ele, o VMS foi feito em cerca de dois anos por uma equipe excepcional de aproximadamente 20 pessoas
- O NT precisava fazer mais coisas, e seu escopo cresceu ao abandonar o i860 e adicionar várias arquiteturas como MIPS, x86 e Alpha
- No processo que levou a Longhorn e Vista, a separação do codebase virou um grande problema
- Depois do Windows 2000, os codebases de servidor e workstation se separaram; enquanto o lado servidor corrigia muitos problemas de segurança, o lado consumidor ficou instável para buildar e executar
- O XP foi um enorme sucesso, mas tinha muitos bugs, e depois o problema de segurança cresceu, exigindo muito esforço na correção de bugs do XP
- O grupo de Cutler corrigiu cerca de 5.000 bugs de segurança relacionados ao XP
- A extensão x64 da AMD foi um ponto de virada importante dentro da Microsoft
- A AMD propôs uma ideia menos intrusiva de extensão para 64 bits capaz de executar rapidamente aplicações de 32 bits
- Cutler decidiu criar workstations e servidores de 64 bits com base no codebase de servidor, e esse não era um projeto oficialmente aprovado pela empresa desde o início
- Quando o sistema da AMD chegou, deram o primeiro boot por CD, e o sistema de 64 bits inicializou e rodou imediatamente
- O
microsoft.comfoi migrado após cerca de uma semana de testes com servidores 64 bits, que foram considerados muito mais estáveis que os sistemas de 32 bits
- Longhorn acabou migrando para o codebase x64, e esse codebase continua até hoje
Estrutura interna do Windows e código que permanece até hoje
- Mesmo no Windows 11, muita coisa das funções e estruturas centrais da era do NT 3.5 ainda permanece
- Código do kernel, estruturas de gerenciamento de memória, estruturas de processo e o gerenciador de objetos continuam presentes
- A proporção do código original dentro do total segue diminuindo, mas uma parte considerável das estruturas centrais que fazem o mesmo trabalho ainda continua lá
- Cutler cita o gerenciador de objetos do NT como uma razão importante para a qualidade do codebase
- Diferentemente da abordagem Unix de “tudo é arquivo”, no NT é possível criar um novo descritor de tipo de objeto, integrá-lo ao gerenciador de objetos e assim adicionar novos objetos de sistema operacional
- Objetos podem oferecer recursos como sincronização e controle de acesso
- A handle table é uma parte importante para desempenho e foi reescrita várias vezes
- A tradução de handles era um problema real de performance
- Como exemplo, ele diz que seu sistema de trabalho tinha cerca de 60 processos, centenas de threads e 150 mil handles abertos
- O aumento de tamanho do Task Manager é citado como exemplo de inchaço de código
- Originalmente, o Task Manager compilava com 85 KB, mas agora teria 4 MB
- Hoje ele mostra muito mais informação, como CPU, rede e disco, mas Cutler não considera que a funcionalidade tenha crescido na mesma proporção
- A decisão de mover drivers gráficos do modo usuário para o modo kernel foi necessária por desempenho, mas trouxe fortes dores de crescimento
- No início, Cutler era contra essa migração para modo kernel
- Como modo usuário e modo kernel têm modelos de sincronização diferentes, não era uma simples transferência de código, e estruturas de dados e primitives de 16 bits também eram um peso
- Depois, a confiabilidade melhorou bastante, embora por um tempo tenha havido muitos problemas com drivers gráficos de fornecedores
Azure, Xbox, xCloud
- Depois de entregar sistemas x64, Cutler ficou frustrado com o problema do fcib e disse que sairia da Microsoft; após incentivo de Steve Ballmer, tirou férias e voltou em novembro de 2005
fcibsignifica checked-in binary, e o uso de binários em vez de código-fonte por alguns grupos dificultava o port
- Depois disso, participou do projeto inicial do Azure
- Ray Ozzie iniciou o projeto ao perceber o problema de não haver uma infraestrutura comum para vários serviços baseados em nuvem
- O Azure inicial visava infraestrutura de plataforma para deployment de aplicações, controle de configuração, versionamento, reinicialização, cobrança e sistema de arquivos em nuvem
- Ele explica que a AWS oferecia algo mais centrado em infraestrutura, enquanto a Microsoft inicialmente queria vender serviços de plataforma
- O hipervisor inicial do Azure foi construído com base em tecnologia vinda da aquisição da Connectix
- A Connectix tinha os produtos Virtual PC e Virtual Server, e também estava em estágio inicial no desenvolvimento de hipervisor
- Mais tarde, o hipervisor do Xbox veio do hipervisor Red Dog do Azure
- O Xbox opera com uma estrutura de três VMs
- O host system é dono de todos os dispositivos e atua como traffic cop da comunicação entre VMs
- A presentation VM cuida do gerenciador de janelas e do sistema de exibição e permanece sempre em execução
- A game VM é iniciada e encerrada por jogo, e o jogo vem empacotado junto com o sistema operacional
- A estrutura em que o jogo é empacotado com o sistema operacional é favorável à retrocompatibilidade
- O desenvolvedor empacota o jogo junto com o SO do GDK, e a VM correspondente é executada junto no momento do uso
- Isso evita que mudanças no sistema operacional quebrem jogos antigos
- Porém, quando era preciso levar alguma função a jogos já existentes, foram necessários contornos como um universal game OS
- O pause/resume do Xbox funciona salvando e restaurando VMs
- O carregamento de jogos envolve dados na casa dos gigabytes, então leva tempo
- O pause/resume salva o estado da VM e o restaura depois
- Como trabalho atual, ele menciona uma VM Linux e a stack gráfica para aproveitar o tempo ocioso dos consoles usados no xCloud
- O xCloud funciona reempacotando consoles Xbox em racks dentro de datacenters para oferecer acesso remoto
- O console é single tenant, então apenas uma pessoa usa por vez, e há períodos ociosos
- Para rodar workloads proprietários de machine learning nesses períodos de inatividade, estão trabalhando em VM Linux, hipervisor do Xbox e stack gráfica
Qualidade, gestão de equipe e filosofia de desenvolvimento
- Cutler aplica às equipes de software a frase “pessoas bem-sucedidas fazem o que as mal-sucedidas se recusam a fazer”
- Ele vê como problema atitudes como: “já escrevi o código, então não vou testar”, “ainda há prazo, mas vou embora às 17h” ou “não quero corrigir meus próprios bugs”
- Considera importante a postura de fazer pessoalmente o que for necessário para levar algo ao sucesso
- Ele valoriza muito o perfil de thinker-doer
- Citando Brooks, afirma que há muitas pessoas que só pensam, poucas que realmente executam e mais raras ainda as que fazem as duas coisas
- Para ele, até arquitetos precisam produzir resultados reais que atendam aos objetivos e às restrições
- Ele queria colocar na parede do laboratório da University of Washington a frase “se você não colocar, não precisa tirar depois”
- Usa isso para enfatizar a disciplina de não adicionar recursos desnecessários
- Nos ambientes iniciais de desenvolvimento, as ferramentas de depuração eram precárias, então era importante ter uma postura de evitar erros desde o começo
- No passado, às vezes era preciso recorrer até a logic analyzer ou oscilloscope
- Hoje as ferramentas ajudam mais a reduzir pequenos erros, mas ele considera que a pressão por qualidade é diferente da de antes
- Ele acredita que multitarefa é possível, mas que a maior produtividade vem do foco em uma única tarefa
- Isso porque context switch custa tempo
- Ainda assim, explica que muda de tarefa para ajudar outras pessoas em problemas travados ou para corrigir bugs
1 comentários
Comentários do Hacker News
O entrevistador, Dave Plummer, também é uma pessoa extremamente interessante por si só. Gosto especialmente dos vídeos de programação retrô como https://www.youtube.com/watch?v=JlZe2JwrJqM e https://www.youtube.com/watch?v=b0zxIfJJLAY
Os vídeos também são divertidos, e a música de fundo junto com a iluminação RGB dá um clima de Natal. Também me fez ver a Microsoft de um jeito completamente diferente da imagem com a qual eu estava acostumado, reconhecendo as esquisitices de Redmond, mas ainda assim falando com carinho sobre seu trabalho, seus colegas e a Microsoft
Só que, quando você assiste a esse canal, o algoritmo do YouTube parece disparar alguma coisa e o feed de recomendações fica lotado de vídeos sobre TDAH. Provavelmente por causa dos vídeos sobre autismo e TDAH, mas eu só vi vídeos sobre programação e a história da Microsoft; parece que o YouTube deveria ser inteligente o bastante para perceber isso
Mas, por mais que eu não goste de dizer isso, é preciso filtrar bastante o que ele fala sobre assuntos fora de Microsoft/Windows. Especialmente depois do comentário abaixo [1]
O caso recente de forçar as pessoas a desativarem o bloqueador de anúncios também foi revelador. Os anúncios do YouTube são realmente os piores, e dá até vergonha pensar que pessoas de verdade reagem àquilo. Parece que o YouTube desistiu até de fingir que quer oferecer uma boa experiência de usuário
Ainda assim, para ver coisas excelentes como esta entrevista com Dave Cutler, vale a pena remexer um pouco na lama
Não é exagero; dizer “metade” é até bastante preciso. Parece que algo quebrou ou que o YouTube acoplou um modelo de linguagem de grande escala ao motor de recomendação
Gostei mais de vê-lo falando de improviso do que em um vídeo bem editado
Depois daquele único vídeo, minhas recomendações ficaram cheias de histórias sobre câncer, pessoas em fase terminal e todo tipo de doença. Aquele vídeo não tinha absolutamente nenhuma relação com o conteúdo habitual daquela pessoa, e eu nem assisti a nenhum desses vídeos recomendados, mas eles continuaram aparecendo
Ainda não vi este vídeo, mas li Showstopper[1] há alguns anos e estou na expectativa.
O que mais me marcou, especialmente quando eu tinha pouco mais de 20 anos e achava que precisava estar sempre trabalhando, foi a parte em que Dave sempre tirava férias na hora certa, sem discussão.
Você pode até não gostar da Microsoft, mas esse provavelmente foi o primeiro exemplo realmente claro que vi de uma pessoa muito competente e plenamente qualificada que não se deixava moer 24 horas por dia, 7 dias por semana.
Ainda parece estranho escrever isso, mas era uma forma de pensar herdada da cultura do interior e do varejo, na linha de que “quanto mais você sofre, mais virtude isso tem”.
Até hoje ainda é difícil descansar direito, e é fácil adiar isso porque X ou Y parece mais importante. Mesmo assim, lembrar da perspectiva do Dave é um bom reminder de que descansar e fazer bem X não são uma escolha excludente.
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
“Lembra-te do dia de sábado, para o santificar... Seis dias trabalharás e farás toda a tua obra, mas o sétimo dia é o sábado do Senhor teu Deus...”
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
Quanto mais o funcionário “mantém o nariz na pedra de amolar” e “se mata de trabalhar”, mais aumenta o lucro da empresa, sem que ela precise pagar mais por isso. Se a saúde dele se deteriorar a ponto de não conseguir mais trabalhar, basta substituí-lo.
Desculpe se soa áspero por ter sido escrito tarde da noite, mas acho que o pessoal daqui já sabe disso intuitivamente de qualquer forma.
Aí veio o burnout, e agora vejo que descansar e, salvo em emergências reais, respeitar uma jornada de 8 horas não é só uma responsabilidade pessoal, mas também uma responsabilidade profissional. Isso reduz o risco de burnout, e burnout é literalmente ruim para todo mundo.
Li que, no fim do desenvolvimento do WinNT 3.1, alguém criou um protetor de tela que mostrava uma tela azul da morte. Acho que talvez tenha sido no Usenet.
Até então eu nunca tinha feito um protetor de tela, mas por causa de um bug no driver de rede interno da Microsoft eu conseguia fazer minha máquina de desenvolvimento WinNT dar tela azul de forma confiável.
Então li a documentação sobre como escrever protetores de tela para Windows, anotei os valores exibidos na minha tela azul e montei de qualquer jeito meu primeiro e último protetor de tela para Windows.
Só pela brincadeira, enviei um e-mail para o grupo do Windows NT avisando sobre o que eu tinha feito, e algumas semanas depois o grupo de build do NT resolveu pregar uma peça no Dave Cutler.
Eles instalaram meu protetor de tela de tela azul em um dos servidores de build, desconectaram também o mouse e o teclado, e ficaram esperando.
Dave Cutler veio verificar o status da build mais recente do NT, ligou o monitor e viu a tela azul. Mexeu o mouse, mas nada aconteceu, e digitou no teclado, mas nada aconteceu.
E então aconteceu algo inesperado. Ele estendeu a mão e apertou o botão de energia do servidor de build para reiniciá-lo. NÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃOOOOOOO
Nunca cheguei a ouvir quais foram as consequências ou o desfecho da brincadeira. Grandes poderes trazem grandes responsabilidades.
Eu também instalei aquilo, e alguns colegas que sentavam perto de mim fizeram o mesmo.
O CTO apareceu para uma reunião bem cedo e, ao ver aquilo em todas as telas, entrou em um leve pânico achando que fosse um vírus se espalhando ou algum bug de software.
Algumas semanas atrás alguém recomendou o livro “Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft”, e eu também recomendo aqui.
Ainda estou lendo, mas está sendo realmente muito divertido, e fico pensando que adoraria ter participado daquela história. Especialmente na parte de fazer dogfooding de um sistema operacional totalmente novo. Só que foi alguns anos antes da minha época.
Graças a esse livro, eu soei como alguém que sabia muito mais do que realmente sabia, e estava muito mais empolgado com toda a área do que alguns dias antes.
Recebi a proposta, mas no fim não aceitei o trabalho.
Relacionado a isso, tem também: https://blog.codinghorror.com/showstopper/
A parte que achei interessante foi que o hipervisor do Xbox não foi feito pelo pessoal do desktop, e sim com base no Azure, e que os jogos de Xbox, em vez de dependerem de um único sistema operacional no aparelho, são empacotados junto com o sistema operacional, ficando mais próximos de um contêiner
O Dave também disse que está trabalhando para fazer tarefas de machine learning rodarem em dispositivos ociosos do Xbox Cloud Gaming. Eu nunca tinha pensado que existisse esse tipo de conexão arquitetural entre Azure e Xbox
Por exemplo, o executável do jogo fica de fato criptografado no disco do jogo, e é quase impossível até mesmo fazer dump do binário real em execução. A RAM também é criptografada
Outro motivo de o TPM moderno ter passado a ficar dentro da CPU foi impedir que as pessoas farejassem o barramento do TPM, como faziam no Xbox
Trabalhei na equipe do kernel do Windows, e minha história favorita sobre o DC é que ele odiava tanto a arquitetura Itanium que basicamente fez o x64 acontecer
Trabalhando com a AMD, ele essencialmente empurrou isso adiante digitando código sem parar no seu escritório de canto
A ideia era que “agrupar várias instruções, às vezes de tamanho variável em bits, em uma única palavra e deixar o autor do compilador encontrar o agrupamento ideal de instruções simplificaria a implementação e a tornaria mais rápida”, mas se o compilador não encontra esse agrupamento ideal, ela acaba sendo mais lenta do que um projeto tradicional como o x86
Alguém muito no alto escalão da Intel claramente amava essa ideia. Eles tentaram isso três vezes e falharam três vezes ao longo de toda a história da Intel como grande fabricante de microprocessadores
Na época, o AMD64 não era visto como uma boa ideia por ser “mais do mesmo”. Ainda assim, o Dave merece crédito por ajudar a remover as tranqueiras que praticamente mataram a revolução RISC
Espero que um dia eu também consiga criar algo tão impressionante no meu tempo livre
Infelizmente para a Microsoft, quem acabou levando esse espólio foi o Linux sobre x86-64
Um dos momentos mais decisivos da minha carreira em engenharia de software foi quando li o código-fonte vazado do NT junto com Showstopper[1], uns 6 ou 7 anos atrás
O que tornava o vazamento do NT especialmente fascinante era que ele incluía todo o histórico de autores, então dava para ver exatamente em quais arquivos Dave Cutler tinha trabalhado. O livro também entra em detalhes sobre coisas como o processo pelo qual módulos do kernel passaram a ter seções pagináveis, o que por si só já é interessante
No livro, há uma cena em que o Cutler entra e refaz uma certa rotina em assembly, e no código-fonte real dá para ver exatamente qual é essa rotina
O código do Cutler era um C realmente bonito, e sem dúvida ainda deve ser. Isso influenciou bastante a forma como escrevo código C no estilo NT
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
A entrevista de história oral de David Cutler no Computer History Museum também é muito boa
Parte 1: https://youtu.be/29RkHH-psrY
Parte 2: https://youtu.be/SVgSLud50ss
Vi alguns trechos da nova entrevista, mas até agora ainda não tenho certeza se há algo realmente novo
Relembrando o que os dois Daves disseram, há uma atenção enorme em terminar e lançar as coisas, mas quase nenhuma conversa sobre planejamento de longo prazo ou uma estratégia de segurança de verdade
É tudo sobre empurrar linguiça para fora do moedor de carne sob pressão comercial e reduzir as falhas a um nível aceitável
Não é surpresa que a situação da indústria como um todo não melhore nem mude de rumo na direção certa. Eu achei que um dia chegaríamos à segurança baseada em capabilities, mas agora parece que vamos ficar presos para sempre ao seu primo quase inútil, os flags de permissões de aplicativos
Estou preocupado com o futuro
Basta ter um ou alguns trimestres, ou alguns anos, bons o suficiente para justificar a promoção de VP para SVP, ou de SVP para CEO. Ninguém vai culpar nem punir alguém que mudou para um novo cargo 3 anos depois por causa de uma decisão míope tomada no cargo anterior
Isso não quer dizer que Cutler seja esse tipo de executivo. Mas ele claramente sofria pressão vinda de cima para lançar e para manter a receita fluindo. Como ele diz no começo da entrevista, ele realmente odeia enviar software com bugs, fica profundamente decepcionado com a qualidade dos engenheiros de software da indústria e também detesta quando gerentes de programa/projeto tratam todo bug como um corner case raro. Concordo com os três pontos
A maioria dos bugs que eu reporto também é tratada como “corner case”, mas eu esbarro nesses problemas todos os dias, e no banco de dados há vários issues duplicados, ou o meu bug acaba sendo marcado como duplicado de um relato ainda mais antigo
Depois de passar décadas nesta indústria, todas em Big Tech, ainda não vi uma empresa que não acabe cedendo ao mesmo tipo de pressão, mesmo quando engenheiros e gerentes de primeira linha pressionam para corrigir bugs antes do lançamento e pedem atualizações de correção com mais frequência
Era um grande argumento de venda, mas para a maioria dos usuários isso não dizia muita coisa. Na prática, muita gente pensava “por que eu preciso disso?”, e isso fazia parecer que não era um sistema operacional para o “usuário comum”
A noção de segurança do começo dos anos 1990 — o que tornava algo seguro e para quem isso era relevante — não combina com as expectativas de hoje nem com o estado da arte atual
Pode levar algum tempo para isso ser feito direito. Enquanto isso, espero que não vença uma alternativa regressiva, de runtime único, meio mal-acabada, que só reforça o status quo
[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
Talvez esse seja o maior produto econômico que o software “nos deu”: um contrato vinculante do tipo “vamos pegar seu dinheiro, mas não prometemos nada, trouxa!”
Na verdade, se você chega em segundo ao mercado, é punido
Estou ansioso para ouvir tudo isso
Independentemente do que se sinta sobre ele ou sobre a empresa em que trabalha, Cutler foi um engenheiro de software extremamente influente por meio de seu trabalho em OpenVMS e Windows NT. Acho que ele não é mencionado com tanta frequência quanto pessoas do Bell Labs, Stallman, Linus ou Stroustrup