Ask HN: Há projetos que foram interrompidos ou encerrados cedo demais? Por quê?

• Pergunta e respostas sobre projetos que desapareceram por estarem à frente do seu tempo ou porque o mercado ainda não estava pronto

  Estou só curioso. Quem sabe alguém adote isso, ou desenvolva algo novo com base nessa ideia.

---

Sistema operacional Plan 9

• Sistema operacional distribuído da Bell Labs, considerado o verdadeiro sucessor do Unix, mas que fracassou na comercialização

  • Design inovador que expandiu a filosofia de "tudo é arquivo" até o compartilhamento em rede
  • Oferecia recursos de UI originais como programação com mouse, gerenciador de janelas aninhadas e Plumber
  • Era ideal para ambientes distribuídos conectando mobile, desktop, cloud e IoT, mas não conseguiu adoção

• Motivos do fracasso

  • Problemas de licença e processos judiciais afastaram a indústria
  • Desalinhamento com a época em que a computação centralizada perdia força e os computadores pessoais estavam em ascensão
  • Foi posicionado apenas como OS de pesquisa e não aproveitou o boom das .com
  • Com a queda da receita do negócio telefônico da AT&T, a Bell Labs foi vendida várias vezes
  • A Version 3 foi vendida por $350 por caixa, mas só podia ser usada para fins não comerciais
  • Não foi devidamente liberado como open source até 2004

• Legado

  • O protocolo de sistema de arquivos 9P continua sendo usado em WSL2, no ecossistema de VMs e no Kubernetes
  • Existem projetos de fork ativos como o 9front
  • A Plan 9 Foundation gerencia o código open source e os direitos

Projetos mortos do Google

• Relato de um usuário cujos 30~40 produtos do Google usados foram reduzidos para 3~4

  • Google Picasa: ferramenta local de gerenciamento de fotos rápida e excelente
  • Google Hangouts: vítima da estratégia confusa de apps de mensagens
  • G Suite Legacy: a promessa de "gratuito para sempre" foi quebrada e virou pago
  • Play Music: enviou milhares de arquivos MP3, mas o fim do serviço causou perda de dados
  • Google Finance: tinha recursos de acompanhamento de ações, mas foi descontinuado
  • Google NFC Wallet: a Apple dominou o mercado com a mesma função
  • Chromecast Audio: era focado em fazer uma coisa só muito bem, mas foi encerrado

• Google Reader: a pior decisão de negócios da história

  • Foi encerrado apesar de ser um serviço que, no longo prazo, quase não exigia manutenção
  • Tinha muitos usuários influentes, como fundadores, CTOs e VPs of Engineering
  • Deixou para a indústria a lição de não confiar nos produtos do Google
  • O encerramento reflete uma cultura organizacional em que economizar alguns milhões de dólares vira mérito

Adobe Flash / Macromedia Flash

• Plataforma de criação multimídia para a qual, mesmo depois de 15 anos, ainda não existe substituto à altura

  • Tornava a criação de jogos e multimídia tão fácil quanto montar blocos de Lego
  • Oferecia um conjunto de ferramentas intuitivo, como MovieClip e animação por timeline
  • Foi substituído por HTML Canvas, mas a qualidade das ferramentas é incomparável

• Por que o iPhone matou o Flash

  • No hardware de 2007, havia sérios problemas de desempenho e consumo de bateria
  • Porque o Flash podia virar um atalho para contornar o ecossistema de apps
  • Havia o risco de fazer o iPhone ser visto como um "produto lixo"

• Situação atual

  • O Adobe Animate oferece suporte a saída JS/Canvas, mas é diferente do original
  • Emuladores como o Ruffle conseguem executar parte do conteúdo legado
  • O Roblox cumpre em parte um papel parecido, mas é mais limitado e comercial

Projetos fracassados da Microsoft

• Silverlight: plugin web baseado em C#

  • Permitía usar C# completo em vez de JavaScript
  • UI vetorial com consciência de DPI, padrão MVVM e binding bidirecional
  • Colaboração entre designers e desenvolvedores via Expression Blend
  • Renderização totalmente idêntica em todos os navegadores
  • O iPhone ajudou a derrubar o Silverlight junto com o Flash

• Midori: OS com segurança baseada em capacidades

  • Evoluiu até conseguir executar código do Windows, mas foi interrompido por política interna
  • Muitos resultados de pesquisa foram integrados ao .NET
  • Recebeu mais de 100 pessoas como projeto de retenção de engenheiros talentosos

Outros

• Copland da Apple (protótipo do MacOS 8)

  • Uma versão modernizada do MacOS sem linha de comando
  • Tinha recursos que poderiam ter facilitado a transição para o mobile
  • Não pôde ser lançado por causa de feature creep e instabilidade
  • Havia rumores de que foi descartado de propósito para justificar a aquisição da NeXT pela Apple

• Songsmith: geração automática de acompanhamento para melodias

  • Em 2009 já fazia detecção de acordes em tempo real e geração de acompanhamento
  • Foi uma precursora das ferramentas de música com IA como Suno e Udio
  • Virou meme por causa de um vídeo promocional cafona, mas a tecnologia era excelente

O declínio do Heroku

• A simplicidade e o foco do início foram os fatores do sucesso

  • Uma única linguagem, uma única plataforma de deploy e um único banco de dados
  • Minimizava a fadiga de decisão
  • Se houvesse IA 15 anos atrás, teria sido mais eficiente com dados de aprendizado consistentes

• Motivos do fracasso

  • Após a aquisição pela Salesforce, a adição de um grande banner de marca gerou reação negativa
  • O surgimento de Docker e Kubernetes tornou a substituição viável
  • O fim do plano gratuito afastou muitos clientes
  • Houve abuso de computação gratuita por causa de criptomoedas

• Situação atual

  • Alguns usuários ainda usam em produção
  • Vercel, Coolify e Dokku oferecem experiências semelhantes

ReactOS - reimplementação do Windows NT

• Está em desenvolvimento há quase 30 anos, mas ainda segue impróprio para uso real

  • Wine + kernel + compatibilidade com drivers de dispositivo + alvo em movimento
  • Mesmo com o fim do suporte ao Windows 10 se aproximando, não conseguiu virar alternativa

• Motivos do fracasso

  • O código-fonte do Windows não é bem documentado nem bem compreendido
  • Pelos princípios de engenharia reversa clean-room, quem viu código do Windows não pode contribuir
  • Mesmo após o vazamento do código-fonte do Windows XP, o ritmo de avanço continuou lento
  • Wine, Proton e tecnologias de virtualização se consolidaram como alternativas práticas

Delphi e Pascal

• Linguagens de programação que eram ideais para ensino

  • Compilador extremamente rápido, ótimo para aprender por tentativa e erro
  • Sistema de tipos limpo (menos complexo que Rust)
  • Muito fiéis ao ensino dos conceitos básicos de programação, sem recursos específicos demais da linguagem

• Situação atual

  • O Delphi segue firme, com lançamento até a versão 13
  • O Lazarus existe como alternativa open source
  • O Python o substituiu como linguagem educacional, mas seu sistema de tipos é confuso

Hardware inovador que fracassou

• MicroChannel (IBM): arquitetura de periféricos baseada em canais

  • Trouxe para o PC o conceito de canal dos mainframes
  • Permitia executar programas de canal simples
  • Fracassou no mercado por causa de licenciamento proprietário
  • Hoje todos os sistemas modernos usam algo parecido, mas sem uma interface unificada

• Motorola 680x0: processador que quase virou a base da era dos microcomputadores

  • Foi lançado em 1978, mas o MMU chegou tarde demais
  • Foi o coração do Amiga e dos primeiros Macintosh

• Memória persistente Optane: tecnologia que apagava a fronteira entre RAM e storage

  • Permitía persistir estruturas de dados diretamente
  • Sem necessidade de boot ou abertura de apps, com retomada imediata de onde parou
  • Fracassou por ser cara demais, embora tecnicamente fosse revolucionária
  • Faltou paciência dos tomadores de decisão de negócio

• Câmera light field Lytro: ajuste de foco após a captura

  • Capturava todos os dados para decidir o foco depois
  • Poderia ter sido perfeitamente compatível com tecnologias modernas como Gaussian splat e Meta Ray-Ban
  • Não entregava a qualidade de imagem exigida por fotógrafos profissionais
  • Talvez devesse ter mirado o mercado de novidade, como Polaroid/Instax

Debates sobre tecnologias web

• O fracasso do XHTML

  • Tentou resolver o caos do HTML com parsing estrito
  • O HTML5 chegou a padronizar até o significado de HTML malformado
  • A lei de Postel estava errada: parsing permissivo causa falhas de segurança e problemas de compatibilidade
  • O princípio de "parar no primeiro erro e mostrar uma mensagem" teria sido melhor

• Contra-argumento: o verdadeiro motivo do fracasso do XHTML

  • O IE6 não suportava application/xhtml+xml
  • Foi preciso manter suporte ao IE6 por quase 15 anos
  • JSX e JSON têm sintaxe estrita e ainda assim deram certo
  • Todas as linguagens de backend usam sintaxe estrita
  • O problema não era barreira de entrada, e sim suporte dos navegadores

• A realidade do HTML

  • Uma aspa errada em um atributo pode impedir a renderização da página inteira
  • Precisa ser um formato que pessoas comuns consigam escrever
  • HTML é um formato de documento, não um conjunto de comandos
  • PDF, ZIP e CSV também leem arquivos corrompidos (os dados importam mais que o formato)

Redes sociais e comunicação

• Google Wave: mostrou o futuro, mas foi uma revolução adiantada demais

  • Tradução em tempo real, integração de várias formas de mensagem e recursos ricos
  • Era totalmente open source
  • A UI era complexa demais, e as "threads aninhadas com atualização em tempo real" eram esmagadoras
  • Já unificava funções hoje espalhadas entre Slack, JIRA e e-mail

• Vine: vídeo curto antes do TikTok

  • Já tinha alcançado escala considerável em 2013
  • O Twitter encerrou porque não sabia monetizar
  • O TikTok foi lançado alguns meses depois do fim do Vine
  • Bastava colocar banners em vídeos quadrados, mas a oportunidade foi perdida

• Skype: videochamada que até avó conseguia usar

  • Era simples como um telefone, mas mais barato que ligação internacional
  • Foi um dos melhores softwares P2P
  • Foi mal substituído pelo Microsoft Teams
  • Configuração difícil de hardware externo, problemas de compatibilidade e ausência do antigo serviço de teste de áudio

Sistemas operacionais

• Maemo/MeeGo: o Linux mobile que a Nokia deveria ter impulsionado

  • O N9 era um aparelho excelente, mas só teve um modelo lançado
  • Reunia hackeabilidade, sofisticação e segurança
  • Hoje poderia haver dois Linux mobile de massa além de Android e iOS
  • Teve alguma continuidade no Sailfish OS

• BeOS: OS otimizado para multimídia

  • É surpreendente que foi preciso rolar tanto para ver menções a BeOS e Amiga
  • A reimplementação from-scratch segue em andamento como Haiku OS
  • Era visivelmente mais rápido e responsivo que Linux+X+Qt+KDE

• OS/2: a tragédia da colaboração entre IBM e Microsoft

  • Um sistema com API excelente
  • Se tivessem aberto o Workplace Shell e o código SOM, poderiam ter sido aproveitados em outros sistemas operacionais
  • Foi usado por muito tempo em caixas eletrônicos bancários sem ser hackeado

Ferramentas de desenvolvimento

• Quartz Composer: programação visual baseada em nós da Apple

  • Ambiente de programação visual baseado em patches
  • Era possível implementar monitoramento de dispositivo USB com 3 nós
  • Parou de receber updates depois de 2016, e muitos nós quebraram nos sistemas mais novos
  • Merece reavaliação com a popularidade da programação baseada em nós em Blender e Unreal Engine

• Atom code editor: quase foi a alternativa ao VS Code

  • Alternativa mainstream criada pelo GitHub
  • Depois que a Microsoft comprou o GitHub, o destino do Atom ficou selado
  • Foi o projeto original do Electron
  • Os desenvolvedores originais estão criando o editor Zed

• Non DAW: DAW separada por função

  • Cada recurso era oferecido como aplicação independente
  • Quando você precisava de só uma função, as outras não atrapalhavam
  • Um exemplo de 25 linhas já apresentava todos os conceitos
  • O principal desenvolvedor foi contratado pela Microsoft e hoje trabalha em Rust OSS

Linguagens de programação

• Elm: linguagem funcional incompleta e sem desenvolvimento ativo

  • A remoção de operadores customizados quebrou todo o código e matou o embalo
  • A Elm Architecture era rígida demais
  • F#, ReasonML, OCaml (Bucklescript), Haskell e PureScript surgiram como alternativas

• Opa: um Next.js orientado a tipos em 2012

  • Antes do TypeScript, já existia um framework full stack com tipos
  • Foi lançado quando o mercado desconfiava de Node.js no lado do servidor
  • A licença AGPL foi o golpe final; depois mudou para MIT, mas não teve segunda chance

• Austral: linguagem com clareza de pensamento e originalidade

  • Oferecia uma especificação com clareza incomum
  • O autor já não trabalha nela ativamente
  • Para programadores hobby, faltam comunidade e ecossistema

• Ceylon: linguagem JVM da Red Hat

  • Competia com Groovy, Kotlin e Scala
  • Tinha tipos união anônimos, comprehensions e um sistema de módulos adequado
  • Oferecia mais do que açúcar sintático simples sobre Java
  • Perdeu a disputa para o Kotlin e foi deixada de lado no Eclipse

Fracassos comerciais

• Google Stadia: plataforma de cloud gaming

  • Construiu uma plataforma de streaming sólida
  • Fracassou por falta de jogos interessantes
  • Não bastava ter poucos jogos que já existiam em outros lugares

• Fire Phone: smartphone da Amazon

  • Mirava um mercado que não existia
  • Olhando em retrospecto, é difícil acreditar que acharam que daria certo

• Project Ara: smartphone modular do Google/Motorola

  • Um smartphone customizável
  • Teria sido bom ver mais algumas iterações de desenvolvimento
  • Provavelmente seria grosso demais para competir

Bancos de dados e backend

• RethinkDB: banco de dados em tempo real

  • Fracassou ao ampliar demais o escopo com o Horizon BaaS
  • Ainda existe tecnicamente na Linux Foundation, mas perdeu embalo
  • O conceito original era excelente para demos, mas faltavam casos reais de produção

• Yahoo Pipes: ferramenta de combinação de RSS e fluxo de dados

  • Mostrava como a internet deveria ser
  • A conexão entre ferramentas ainda está presa ao nível dos pipes do Unix
  • Zapier e n8n são substitutos modernos, mas não têm a mesma sensação
  • Node-RED, Apache Camel e Apache Nifi são alternativas enterprise

Outros projetos dignos de nota

• Sandstorm: plataforma web distribuída de 2014

  • Baseada em ideias do BitTorrent
  • Código e dados de sites totalmente distribuídos
  • Poderia ter sido integrada a sites existentes
  • O mecanismo de Grain (isolamento de dados) dificultava adaptar apps existentes
  • Em vez de focar em portar apps, talvez devesse ter promovido criar apps do zero na plataforma

• Keybase: rede social baseada em criptografia

  • Oferecia criptografia forte e verificação de identidade
  • Foi praticamente encerrada após a aquisição pela Zoom
  • FOKS é o novo projeto dos desenvolvedores originais

• del.icio.us: serviço de bookmarking social

  • Permitía compartilhar bookmarks com pessoas que você realmente conhecia
  • Tinha tagueamento útil por categorias
  • Foi substituído por Reddit e Twitter
  • O Pinboard oferecia um serviço semelhante, mas sofreu com má gestão e com as opiniões políticas do fundador, afastando usuários

[soonil]

São tecnologias que trazem de volta muitas lembranças.

[roxie]

Ah.. o projeto Keybase foi descontinuado??

[click]

Eu usava muito o Vine; se ele tivesse sobrevivido até a era dos vídeos curtos, provavelmente teria ganhado bastante dinheiro como pioneiro do setor de short-form.

[unknowncyder]

Berryz WebShare?.. Lembro que, quando era criança, usei bastante porque era bem fácil e prático, mesmo sem ter praticamente nenhum conhecimento.

[chicol]

Faltou o Cyworld..

[GN⁺]

Comentários do Hacker News

• O sistema operacional Plan 9. Era o sistema mais próximo de ser o sucessor do Unix, levando a filosofia de “tudo é arquivo” um passo além, permitindo compartilhar arquivos facilmente pela rede e construir sistemas distribuídos. No Plan 9, o acesso a recursos remotos era fácil e confiável, enquanto em outros sistemas era preciso instalar softwares pouco compatíveis para cada caso de uso. Também tinha recursos de UI inovadores, como edição de texto baseada em mouse chording, gerenciador de janelas aninhadas e o Plumber, que executava comandos em todo o sistema com base em padrões de texto. Graças à arquitetura distribuída, teria sido ideal para a era atual de dispositivos móveis, desktops, nuvem e IoT interconectados, mas seguimos presos a sistemas operacionais que não foram projetados assim. Hoje ainda existem forks vivos como o 9front, mas o original do Bell Labs desapareceu. As razões do fracasso incluem problemas legais, como licença e processos, que dificultaram a adoção pela indústria; na época em que um SO distribuído fazia mais sentido, as pessoas preferiam computadores locais; além disso, ele ficou conhecido apenas como SO de pesquisa e não aproveitou direito o boom das pontocom. Por fim, a perda de fontes de receita da AT&T, a venda do Bell Labs e a saída de membros centrais também influenciaram

  • A maior razão para o fracasso do Plan 9 foi que, ao contrário do Unix, fabricantes de hardware não podiam licenciá-lo de forma barata e modificá-lo livremente para seus próprios equipamentos. O Bell Labs tentou vender o Plan 9 como software comercial por US$ 350, e isso impediu sua adoção adequada pela indústria. Já destaquei isso várias vezes antes e recomendo estes textos: link1, link2, link3

  • O protocolo de sistema de arquivos do Plan 9 continua vivo dentro do WSL2

  • Tenho curiosidade sobre por que outros sistemas da família Unix não adotam de forma mais agressiva a filosofia de “tudo é arquivo”

  • No Plan 9, o problema dos links simbólicos foi resolvido

• A interface gráfica Photon do QNX também era focada em tempo real, mas ainda assim tinha bons widgets, medidores etc., e ainda suportava dois navegadores web, tudo sem latência. Parecia um verdadeiro sistema operacional de tempo real. E o Mac OS 8, conhecido como Copland, modernizava o Mac OS original mantendo a tradição de não ter linha de comando. Sem linha de comando, toda instalação e configuração precisava ser fácil e consistente, e se tivesse havido uma transição para o mundo móvel, acho que ela teria sido suave. Na verdade, uma versão real chegou a ser fornecida a desenvolvedores, mas o projeto Copland foi engavetado porque a Apple precisou adquirir a NeXT. Além disso, o conceito de sistema operacional transacional também era inovador. Como no CICS da IBM, o programa era carregado, executado e encerrado, em contraste com o fato de Unix e Linux serem fundamentalmente sistemas de timesharing baseados em terminal. Em seguida, o IBM MicroChannel tentou trazer as vantagens dos canais de mainframe para o PC, mas fracassou por causa de políticas essencialmente monopolistas. Hoje quase todos os sistemas usam conceitos parecidos, mas sem funcionar como uma interface integrada que simplifique o SO. E CPUs com hipervisor realmente funcional também: diferente dos antigos sistemas IBM VM, no x86 todas as camadas são cheias de gambiarra. A série Motorola 680x0 deveria ter sido a base da era dos microcomputadores, mas o MMU chegou tarde demais e perdeu o embalo. Modula-2 e 3 eram bem interessantes, mas Oberon fracassou, e a DEC caiu junto. No caso do XHTML, o HTML5 oficializou erros e acabou introduzindo regras de parsing desnecessariamente permissivas. Bastava uma tag não fechada direito em um anúncio ou código externo para quebrar toda a página de forma sem sentido. Por fim, houve inovações como o Word Lens, em que você apontava o smartphone para o mundo e já tinha tradução automática com processamento offline, mas isso desapareceu ao ser incorporado ao Google Tradutor

  • Quero corrigir os fatos sobre o projeto Copland. Esse projeto foi gerenciado de forma extremamente ruim, com adição desenfreada de novas tecnologias, o que causou um caso sério de feature creep e queda de estabilidade. Se você usar builds vazadas, vai ver que até funções básicas do desktop travavam e quebravam com frequência. Em 1996, a Apple concluiu internamente que o Copland era impossível de lançar, começou a avaliar o licenciamento de sistemas externos e acabou comprando a NeXT. Não foi uma questão de abandonar o Copland para comprar a NeXT; o Copland estava em um nível tão inviável que não havia alternativa

  • Houve uma época em que eu era obcecado por XHTML, mas tive a experiência de ver uma página inteira deixar de aparecer e mostrar só uma grande mensagem de erro porque uma única tag em um anúncio, fora do meu controle, não estava fechada corretamente. A abordagem de “renderizar o resto em Times New Roman” também não é prática. Se no fundo você já está parseando HTML, então não há diferença real em relação ao que havia antes. Como entusiasta, eu conseguia escrever meu código perfeitamente, mas na prática a maioria das pessoas faz tudo de qualquer jeito. XHTML pode parecer logicamente elegante, mas no mundo real era uma abordagem impossível por causa da natureza humana

  • Você pode gostar de um estilo rigoroso como o do XHTML, mas um framework sem tolerância não combina com documentos web amplamente compartilhados. Pensando em formatos de arquivo, eu dividiria em dois tipos: (1) loop aberto, em que o consumidor não pode contatar o autor, como HTML, pdf, zip, csv etc.; aí os dados em si importam mais do que o formato, então até pdf ou zip corrompido precisa ser lido. (2) loop fechado, em que o consumidor pode controlar o autor, como código-fonte de programas; aí um parser estrito é aceitável. XHTML é um modelo que só funciona no caso (2), mas HTML é claramente do tipo (1). A menos que seja um ambiente inerentemente fechado, como documentos internos de empresa, é difícil aplicar XHTML

  • Sou crítico dessa tolerância excessiva do HTML5 com erros de tags. A maioria dos outros formatos para no primeiro erro, mas o HTML é exceção. Isso gerou muitas vulnerabilidades de segurança e só tornou as coisas mais difíceis para os desenvolvedores. A linha adotada pelo parsing do HTML5 acabou indo longe demais, seja por idealismo excessivo de quem se opunha ao Internet Explorer, seja por uma tendência de documentar bugs em nome do padrão. RFC relacionada

  • Exigir que as tags sejam fechadas “corretamente” só aumenta a barreira de entrada da linguagem. Antigamente, muita gente continuava tentando escrever HTML à mão porque, mesmo com erros, alguma coisa aparecia na tela. Linguagens de programação de verdade costumam despejar mensagens de erro terríveis por pequenos deslizes, e isso faz muita gente desistir facilmente. Linguagens recentes melhoraram isso, como Rust, mas na época do XHTML até erros pequenos eram difíceis de diagnosticar

• Eu escolheria o Google Wave. Vi a primeira demonstração do Chris DiBona e achei incrível. Tinha tradução em tempo real, integração de várias formas de mensagem, era open source e cheio de recursos ótimos. Mas o Wave lançado de fato era uma versão reduzida, e o mercado também o ignorou, o que foi muito frustrante. No fim, restaram coisas como JIRA, Slack e email, e isso só reforça a falta que o Wave faz

  • O stack tecnológico do Google Wave era excelente, mas ele cometeu um erro fatal no design da UI. Em vez de tratar um wave como um documento único, tratava-o como vários itens separados, o que só o fazia parecer complicado e eliminava suas vantagens

  • Fiquei impressionado com a demo, mas logo depois pensei melhor e concluí que seria horrível. Como no Slack, você já precisa acompanhar atualizações de cada canal uma a uma; no Wave essa estrutura era muito mais complexa, então tive a sensação imediata de que ninguém conseguiria acompanhar

  • A tecnologia do Wave era impressionante, mas ao rever os vídeos de demonstração fica claro que não era um produto muito bom. Tentou ser um produto tudo-em-um para cobrir tudo, mas não deu certo. Em vez disso, essas tecnologias acabaram espalhadas por vários produtos do Google, e ficou claro que UIs separadas por função eram muito mais intuitivas

  • Era perfeito para administrar coisas compartilhadas com amigos, como roteiros de viagem, e o formato do Wave também funcionava bem para discussões ad hoc com documentos e links. Parecia o futuro, a ponto de eu ter feito meu próprio plugin de administração de servidores quando ainda era iniciante: Wave-ServerAdmin. Já se passaram 16 anos, então talvez seja hora de arquivar

  • Cheguei a baixar o servidor open source do Wave pensando em construir algum produto em cima dele, mas a maior limitação era que ele não conseguia armazenar os dados de forma permanente. Para mim, isso significava que não havia futuro, e a reação das pessoas da equipe do Wave parecia de quem estava fora da realidade e vivendo uma fantasia. Ainda assim, era um conceito legal

• Adobe Flash / Shockwave: mesmo depois de décadas, ainda não existe ferramenta tão fácil quanto essa para criar jogos e multimídia. Isso lembra que a humanidade nem sempre avança em linha reta; às vezes perdemos para sempre algo valioso no caminho

  • Como até iniciantes conseguiam criar jogos com facilidade, isso despejou uma enxurrada de ideias novas no setor inteiro de games. Por exemplo, desenvolvedores indie como a Zachtronics estrearam dessa forma. Por outro lado, cada jogo em Flash vinha cercado por um monte de anúncios, além de navegação tosca feita em Flash; houve uma época em que praticamente todos os sites de restaurante eram em Flash. Players de vídeo em Flash eram um tormento no Linux e foram um dos principais culpados por atrasar o suporte decente a vídeo nos navegadores

  • Flash foi um desastre para a web. Era uma caixa preta em que nada funcionava: zoom, seleção de texto, voltar etc. O fato de ter morrido parece até a maior realização do Steve Jobs

  • O Godot chega bem perto. É fácil de aprender, suporta 2D e 3D, e exporta amplamente para os principais sistemas operacionais, mobile e HTML5/webasm. Ainda não é perfeito, mas avançou muito nos últimos anos e parece estar chegando a um ponto de virada importante, como aconteceu com o Blender

  • Mesmo que a Adobe tivesse resolvido completamente os problemas de segurança, a Apple teria matado o Flash de qualquer jeito. O sucesso popular do Flash era uma ameaça para a Apple. E mesmo agora, com toda a onda em torno de HTML canvas já tendo esfriado, ainda não existe um substituto que permita a designers criar interações bonitas sem assinatura e embutir isso em qualquer lugar

  • O problema foi o abuso excessivo do Flash. No trabalho, um aplicativo insistia em usar Flash até o fim, e quando fui descobrir por quê era porque uma simples linha divisória horizontal da página tinha sido feita em Flash. Menus dropdown em Flash, splash screen de site de carro, tudo isso era mau uso. Só morreu de verdade quando chegou a era mobile, e nessa altura quase ninguém sentiu falta

• Há inúmeros serviços do Google que podem ser vistos em killedbygoogle.com. Eu já usei uns 30 ou 40; hoje uso só 3 ou 4. O Google Picasa era rápido no uso local, o Google Hangouts virou uma bagunça por causa da quantidade de apps de chat, o G Suite Legacy prometia ser gratuito para sempre mas acabou pago e me fez sair do Google. No Google Play Music eu tinha milhares de MP3 enviados, mas com o fim do serviço não pretendo reenviar tudo. Também abandonei o Google Finance e o NFC Wallet porque deixei de confiar nos dados. O Chromecast Audio fazia exatamente aquela única coisa de que eu precisava e, quando soube da descontinuação, logo vendi o meu. Só fui descobrir que o Chromecast também tinha sido morto enquanto ainda usava

  • Ainda sinto muita falta do Google Reader. Nem devia custar tanto para operar, e era daquelas coisas que poderiam passar anos sem correção nenhuma que ainda assim ninguém reclamaria. Antes e agora, continuo usando RSS do mesmo jeito

  • As músicas enviadas para o Google Play Music não sumiram necessariamente. Se você migrou para o YouTube Music, tudo foi transferido sem precisar reenviar

  • O Chromecast Audio continua funcionando muito bem. Só não é mais vendido, por isso continuo sempre de olho em unidades usadas

  • O reconhecimento facial do Picasa estava à frente do seu tempo, e o pacote offline era realmente muito bom. Infelizmente, a última versão tinha um bug em que as tags de rosto mudavam aleatoriamente, inutilizando o reconhecimento em milhares de fotos de família. O Digikam mal consegue cumprir um papel parecido e é um substituto fraco

  • É curioso que o Google tenha encerrado o Google Notebook e, anos depois, criado o Google Keep com praticamente as mesmas funções

• A câmera light field da Lytro era tecnicamente impressionante, e eles até lançaram dois produtos, mas a resolução ficava aquém do que fotógrafos profissionais precisavam. Porém, agora com mídias como o display light field do Meta Ray-Ban e gaussian splats, parece que finalmente chegamos a um ponto em que mais dados de sensor podem ser aproveitados. Fora o lado técnico, também existe um grande mercado para câmeras inventivas e de baixa resolução, como Polaroid e Instax, então a primeira Lytro poderia ter sido um formato divertido até com uma impressora embutida

  • Light field registra a imagem misturando pixels em várias profundidades de foco, então o resultado inevitavelmente acaba tendo resolução inferior à de uma câmera comum. Não é difícil de fabricar, mas é uma pena haver esse limite físico

  • Hoje em dia parece que até smartphones implementam parte dessa ideia. Lembro de ter ficado bem empolgado quando a câmera da Lytro apareceu

• A memória persistente Optane tinha um valor revolucionário: gravar dados diretamente e retomar o uso sem boot nem carregamento de apps. Fracassou por ser cara demais, mas as limitações já eram evidentes antes disso. Ainda assim, essa linha de pensamento não desapareceu por completo por causa de coisas como snapshots de memória em VMs e containers do macOS

  • Tenho fé ilimitada na tecnologia 3dxpoint. É uma tecnologia amadurecida ao longo de décadas, mas do lado dos negócios não houve paciência para esperar o mundo acompanhá-la

  • A forma tradicional de pensar sistemas, presa à separação entre RAM e disco, ainda não estava pronta para absorver um hardware novo como o Optane. Mesmo assim, surgiram alguns casos de uso no mundo dos servidores, além de muitos projetos de pesquisa relacionados

  • O Optane era tecnicamente incrível. Quase apagou a fronteira entre RAM e disco; dava a impressão de que um único stick poderia concentrar toda a memória

  • Eu realmente mantenho o kernel em um drive Optane e experimento boot instantâneo

  • Não foi só por preço; faltou massa crítica no ecossistema, e o modo de pensar existente também não estava pronto. É um modelo mais próximo de ambientes baseados em imagem (live image), como Lisp e Smalltalk antigos. Eu mesmo tenho um sistema com firmware e Optane de baixa capacidade suportados. A capacidade é pequena e presa a um SO antigo, mas ainda vale experimentar. Com RAM suficiente, também dá para imitar isso com suspend/resume. Juntando isso com a evolução dos SSDs, a diferença de velocidade quase desaparece. Só sobra a durabilidade, como TBW. Também dá para misturar os dois

• A rede Ricochet era um sistema peculiar que, na era das linhas telefônicas, oferecia velocidades nível ISDN com uma malha sem fio de pacotes. Foram investidos US$ 5 bilhões em redes de 23 cidades, mas praticamente não houve clientes, e a empresa fechou em 2001. O marketing foi direcionado a “profissionais móveis”, quando na prática ignorou o mercado doméstico, que queria internet mais rápida. Hoje femtocells 5G lembram o conceito físico, mas sem a mesma redundância e capacidade de autorroteamento

  • O Ricochet era um sistema incrível e muito à frente do seu tempo. Também recomendo a reflexão que Joel Spolsky escreveu: review do modem Ricochet Wireless

  • Eu amava o modem Ricochet. Tenho ótimas lembranças de levar um Ricochet de segunda geração e um PowerBook para cafés em Palo Alto para navegar na web a 56k e abrir sessões ssh. Acho que ainda tenho a caixa em algum lugar de casa e às vezes penso em tentar conectá-lo em modo star só pela diversão

  • Usei um modem Ricochet em San Francisco em 98–99. Dez anos depois, o iPhone inaugurou a era do 3G, e a melhora de desempenho foi esmagadora. Quando penso se minha vida teria sido melhor se o Ricochet tivesse sobrevivido, acabo achando que o progresso tecnológico tomou um rumo muito mais acertado

  • Eu tinha esquecido completamente esse serviço, mas pensando bem, naquela época ele era realmente impressionante. Acho que eu também era um dos quatro únicos clientes

• O Midori da Microsoft era um SO voltado para segurança baseada em capacidades. Segundo rumores, teria sido desenvolvido a ponto de conseguir executar código Windows, mas acabou descartado por política interna. Era algo como um antecessor do Fuchsia. Wiki do Midori

  • O Midori era realmente fascinante. O blog do Joe Duffy talvez seja a fonte mais detalhada que existe: blog sobre o Midori. Dentro da Microsoft, também há quem diga que era um moonshot e um projeto para reter talentos-chave. Mais de cem engenheiros, muitos deles muito seniores, foram envolvidos. Parte dos resultados da pesquisa acabou aproveitada no .NET, então nem tudo desapareceu por completo

  • Não sei de onde veio esse rumor de executar código Windows. Toda a documentação pública indica que o Midori buscava incompatibilidade total com o código legado. Talvez internamente alguém sonhasse com uma migração, mas o projeto em si era um sistema novo radical, sem transição real

  • A base técnica é interessante, mas sendo Microsoft, provavelmente teria acabado virando um software inchado cheio de novos problemas específicos. A esta altura já estaria abarrotado de spyware e recursos de IA que os usuários nunca pediram

  • Queria saber se você conhece o Genode(genode.org). Ele ocupa um espaço parecido com o do Midori e continua em desenvolvimento ativo

• O Yahoo Pipes era ótimo para criar feeds RSS e workflows personalizados. Hoje existem substitutos como Zapier e n8n, mas eu gostava especialmente do Pipes. E também concordo com a nostalgia em relação ao Google Reader

  • Recomendo muito ler o arquivo A história do Pipes. Ele traz recordações do time real de desenvolvimento

  • O Yahoo Pipes era o futuro que a internet deveria ter seguido. Décadas depois, esse tipo de integração entre ferramentas ainda só existe de forma rudimentar, no nível de unix pipes

  • Nunca usei pessoalmente, mas sempre que ouço essas lembranças positivas sobre o Pipes, fica claro que era uma ferramenta extraordinária. Às vezes nem sei se o que morreu foi realmente o Pipes ou se foi a internet popular baseada em padrões e protocolos abertos

  • Eu adorava o Pipes. Reunia conteúdo de vários sites, formatava tudo nele e puxava o resultado por RSS para um blog em php. Mas, à medida que os sites foram abandonando o RSS um a um, o Pipes também perdeu sentido e acabou encerrado. Por um tempo usei riko, uma biblioteca Python, para obter algo parecido sem editor visual, e isso acabou sendo uma porta de entrada para eu migrar de PHP para Python

  • Se você quiser reviver a ideia do Yahoo! Pipes, Node-RED é um ótimo ponto de partida. É open source, tem APIs sólidas, mais de dez anos de experiência acumulada e um backend robusto. Já usei até o Browser-Red, que reaproveita só o frontend do Node-RED, e o Erlang-Red, que o reimplementa com backend em Erlang. A diferença é que no Node-RED todos os nós têm uma única porta de entrada ou nenhuma, enquanto o Pipes aceitava várias entradas. O frontend também é fácil de aprender se você conhece jQuery. Se tiver dúvidas sobre Node-RED ou flow-based programming, pode falar comigo a qualquer hora