Linus Torvalds & Dirk Hohndel: Linux, Rust e Mantenedores

[0:00] Agora tenho o prazer de apresentar nosso próximo palestrante para a conversa. Por favor, deem as boas-vindas--por favor, deem as boas-vindas ao palco, Dirk Hohndel, o chefe do Open Source Program Office na Verizon e o criador do Linux e do Git, Linus Torvalds. Por favor, deem as boas-vindas. Tchau.

[0:31] Obrigado. Bom dia. É tão engraçado ver todos esses celulares apontados para nós. Eu quero pegar meu celular e tirar uma foto de todos vocês, mas deixei meu telefone ali. Eu sou Dirk Hohndel, comando o código aberto na Verizon, e citando Jim Zemlin, este é aquele outro cara. Sim. Sim, eu sou o outro cara, e já fiz isso antes, e já fizemos isso. Dirk disse que aparentemente esta é a 23ª vez que fazemos isso.

[1:04] E a razão de fazermos assim é que eu não gosto de dar palestras públicas. Tenho certeza de que muitos de vocês entendem que não é a coisa mais divertida do mundo, então criamos este formato em que Dirk prepara perguntas que eu não sei de antemão, e temos mais uma discussão na frente de vocês, e isso me deixa muito mais confortável e espero que funcione para vocês também. Sim, e geralmente funciona bem. E ocasionalmente ele me joga bolas curvas que me fazem pensar, o que eu faço agora? Então vamos ver qual é esta. Estou emocionado por estar de volta ao Japão. Já faz alguns anos.

[1:43] infelizmente. Fizemos nosso tradicional jantar de sushi ontem à noite e é sempre bom estar aqui. Muito obrigado por nos receber. O timing mudou. Costumava ser que as conferências no Japão eram tipo em junho. E então estar aqui antes do Natal é na verdade meio divertido. Então estou-- bastante feliz. - E tivemos sorte com o tempo também. - Sim, tem estado lindo. Então Linus, você lançou o Linux 6.7 RC4 alguns dias atrás.

[2:16] E uma das coisas divertidas que surgiram nisso é que teremos um kernel de Natal e Ano Novo. Muito bem. Bom timing. Bem, quero dizer, temos lançamentos a cada... dois meses e meio, acho que 10 semanas é basicamente o que tento alcançar. Então isso acontece toda vez que o Natal chega, e temos a janela de merge, que é meu período ocupado, bem perto do Natal, o que realmente destrói o Natal para mim. Ou temos o período tranquilo.

[2:54] quando estamos apenas tentando encontrar e corrigir os últimos bugs. E este ano, felizmente, o Natal para mim é o período tranquilo quando as últimas semanas do lançamento estão acontecendo e estamos apenas esperando para garantir que não temos nada grande acontecendo que seja um impedimento. E isso funciona muito bem para mim, mas significa que Todos os... alguns mantenedores e desenvolvedores que agora estão se preparando para a próxima versão, 6.8, Eles vão-- eles vão estar em um leve pânico só porque sabem que depois do Natal minha janela de merge abre, e é quando eles devem ter todas as suas coisas prontas para a próxima versão.

[3:39] Então provavelmente vamos atrasar isso em uma ou duas semanas só porque Fazemos isso todo ano para fazer o timing funcionar melhor porque ninguém quer trabalhar no Natal. Sim, mas então com 6.7, o que é empolgante? Algo que se destaque para você. Hum... Na verdade, tivemos nos últimos, quase 20--não, não 20 anos mas 15 mais anos, tivemos um cronograma de lançamento muito regular. Estou feliz em dizer que 6.7 está se revelando um dos lançamentos entediantes. Entediante é bom. - Entediante é bom. - Você não quer ter muita emoção, porque emoção geralmente significa grandes bugs.

[4:23] 6.7 é-- - Bugs com G, não com CK. - Sim. Sim. Obrigado. Horrível. Mas 6.7 é na verdade um pouco incomum. Acho que pode ser o maior lançamento que já tivemos se você apenas contar o número de commits. E, uh, A razão para isso é que na verdade temos um novo sistema de arquivos que está em desenvolvimento há tipo uma década.

[4:56] Há muitos novos commits chegando para isso. Mas ainda é interessante ver que não apenas estamos mantendo o ritmo, como na verdade ainda estamos aumentando a velocidade de desenvolvimento. E os tamanhos do Kernel tendem a aumentar, o que é um bom sinal, mas obviamente também significa que há muito mais trabalho acontecendo e muito mais trabalho para os mantenedores lidarem. Sim, além do Linus não ter gostado da minha piada, quero pedir desculpas aos tradutores simultâneos, porque não tenho ideia de como vocês traduziriam isso para o japonês.

[5:36] Então, uma das coisas sobre as quais falamos muito nas últimas versões do kernel é a introdução do Rust no kernel. E acho que tem sido relativamente estável e tranquilo. Qual é a sua percepção? - Bem, o resto ainda está no ponto em que não temos, temos, a infraestrutura inicial foi mesclada no ano passado. Tem crescido, mas ainda não temos nenhuma parte do kernel que realmente dependa do Rust. Para mim, o Rust foi uma daquelas coisas que, em primeiro lugar, fazia sentido técnico, mas para mim pessoalmente ainda mais importante foi que precisamos não estagnar como kernel e como desenvolvedores.

[6:22] E então eu sempre fico empolgado em tentar algo novo e não ficar muito confortável fazendo a mesma coisa. Quer dizer, estou trabalhando no kernel agora há 32 anos. Sim, 32 anos. E é muito tempo para trabalhar em uma única coisa, mas ainda é interessante porque não é a mesma única coisa. Quer dizer, o Linux de 32 anos atrás era muito diferente do Linux de hoje, obviamente. Na verdade, muitas vezes procuro coisas onde podemos fazer coisas novas e podemos fazer as coisas de maneira diferente, porque é tão fácil ficar na mesmice e dizer: 'Isso está funcionando muito bem', certo?

[7:06] e o Rust não se mostrou realmente como a próxima grande coisa, mas acho que durante o próximo ano, na verdade estaremos começando a integrar e alguns subsistemas até importantes começando a usá-lo ativamente. Então é uma dessas coisas. Vai levar anos antes que seja uma grande parte do kernel. Certamente está se moldando para ser uma dessas. - Então você está escrevendo código Rust você mesmo? Você está revisando código Rust? - Ah, não. Tenho lido um pouco de código Rust só para poder fazer algum tipo de julgamento sobre quando algo é horrível demais para ser incluído no kernel. Mas tenho que admitir, não.

[7:54] Quer dizer, o kernel Dependemos de literalmente milhares de pessoas. A cada versão que lançamos, mil pessoas envolvidas, e não são as mesmas mil pessoas. Muitas vezes temos pessoas, na verdade, por muito tempo, tivemos estatísticas de que aproximadamente a cada versão... cerca de metade das pessoas envolvidas envia apenas um patch. E muitas delas nunca aparecem novamente. Elas podem ter algo pequeno que queriam corrigir e com que se importavam, e não eram realmente pessoas do kernel. Elas descobriram isso por algum outro motivo.

[8:29] e enviaram seu pequeno patch para o kernel. E nunca estiveram interessadas em fazer mais nada. Mas então... A outra metade continua voltando. E quando se trata de Rust, não serei eu quem vai gerenciar o subsistema Rust porque essa não é minha especialidade, como é verdade para tantas outras partes do kernel. Honestamente, sou menos programador hoje do que era; eu me chamo de líder técnico porque não sou gerente.

[9:03] Eu não gerencio pessoas, gerencio código. Então me chamo de líder técnico. Não é... meu trabalho diário não é programar, é mesclar o código dos outros e o Rust será um desses casos. Sim, então o Jim em seu keynote apontou que desenvolvedores de código aberto às vezes são opinativos. Às vezes expressam suas opiniões. - Desculpe? - Você teve no passado uma reputação de ser expressivo e não ultimamente, é claro, mas uma das coisas sobre as quais tenho me perguntado, então quem está atualmente na sua lista negra? Quais são as empresas que podem... Ah, não vou entrar nessa.

[9:46] Eu entrei nessa... Podemos ver um show de mãos? Ele deveria entrar nessa? Não, não, não. É uma daquelas coisas que você... dá o dedo do meio para alguma empresa há 20 anos. E essa foto continua aparecendo todo dia. Então aprendi minha lição. Acho que ainda é o resultado número um de busca quando você procura imagens suas. Acho que ainda é o primeiro resultado, sim. Mas quer dizer, para ser honesto, eu brinco, mas ao mesmo tempo, todo o ambiente comercial melhorou muito nos últimos 20 anos. Costumávamos estar na situação em que era difícil encontrar documentação para hardware.

[10:27] E algumas empresas eram ativamente hostis. E isso simplesmente não é mais verdade. Quer dizer, agora temos empresas que escrevem drivers para seu próprio hardware, e às vezes é tão difícil encontrar documentação porque escrever documentação é difícil. E muitas empresas não querem necessariamente documentar algumas das peculiaridades ou bugs em seu hardware, mas estamos em uma posição tão boa quando se trata de suporte a hardware

[10:57] comparado a onde costumávamos estar. Então você falou sobre o ambiente em mudança. A Kernel Summit foi há apenas algumas semanas. E um dos tópicos que tem sido muito comum na Kernel Summit por muitos anos é essa questão geral da fadiga dos mantenedores e quão desgastante e estressante é esse papel. O que estamos fazendo para melhorar a situação, que não é apenas para os mantenedores individuais, mas para o ecossistema Linux e para o ecossistema de código aberto em geral, eu acho.

[11:35] Então, quer dizer, parece... digo, isso tem sido uma coisa que surge há muito tempo. Acontece que é difícil encontrar mantenedores. É muito mais fácil encontrar desenvolvedores. Temos muitos desenvolvedores. Toda versão é mencionada. Mas para ser um mantenedor, hmm, algumas pessoas pensam que você precisa ser esse tipo de super desenvolvedor que pode fazer tudo, mas isso não é realmente verdade. Mas para ser um mantenedor, você precisa ter uma certa dose de bom gosto para poder julgar o código dos outros.

[12:08] e parte disso talvez seja inato, mas muito disso é apenas prática. Olhar o código dos outros e ser capaz de dizer facilmente: essa é uma boa abordagem ou uma abordagem ruim? Geralmente é só uma questão de ter feito isso por muitos anos. Então, para ser um mantenedor e ser bom no seu trabalho, você tem que fazer isso por muito tempo. E temos muitos mantenedores excelentes, mas a outra parte é que você tem que estar lá o tempo todo.

[12:42] ou você tem que encontrar outros mantenedores com quem possa trabalhar para que você programe em torno das suas férias e coisas do tipo. Para mim, estar lá o tempo todo não é um problema porque amo o que faço. Eu estava de férias há alguns meses e levei meu laptop comigo. E se eu não tivesse... meu laptop comigo, teria ficado tão entediado. Porque é o que faço, e é o que venho fazendo há muito tempo.

[13:17] Mas percebo que essa não é a vida para todo mundo, especialmente quando você tem que investir anos da sua vida nisso. Então não temos uma solução para isso. Temos conversado sobre diferentes soluções e muitos dos nossos grupos de mantenedores formaram soluções diferentes, e acontece que um dos problemas é que pessoas são difíceis. Código é fácil. Para escrever código você tem uma resposta certa e uma resposta errada. Relacionamentos pessoais são difíceis e ser capaz de trabalhar com outros desenvolvedores, trabalhar com outros mantenedores, e trabalhar, especialmente quando você tem mantenedores que trabalham em coisas diferentes e têm objetivos diferentes, e querem empurrar sua área em uma direção e outro mantenedor vem de outra área e quer puxá-la em outra direção.

[14:09] Pode ser muito estressante e é uma daquelas coisas em que muitas pessoas parecem pensar que código aberto é só programação? Mas... muito disso é sobre comunicação também. E não precisa ser a mesma pessoa. Muitas vezes é bom ter, você tem seu programador que não tem muitas habilidades sociais. Acontece, certo? E então você pode precisar ter um mantenedor que seja o tradutor, e digo traduzir não... quer dizer, no Japão, temos a questão do idioma também em muitos programas de código aberto.

[14:50] projeto, mas quando digo traduzir, não me refiro necessariamente ao idioma. Refiro-me ao contexto. A razão do código. Hmm, e isso é novamente uma daquelas funções de um mantenedor, meio que pegar a produção do desenvolvedor e traduzi-la para o projeto e, novamente, torna-se um trabalho difícil e para um certo tipo de pessoa. E temos sorte de ter tantos mantenedores quanto temos. Se você quer ser um mantenedor, confie em mim, há espaço no topo. Mas é exatamente para onde eu queria ir em seguida. Porque se você olhar para o topo, se olhar para as pessoas no nível de sub-mantenedor.

[15:37] A maioria deles hoje em dia ou é como o Greg e não tem cabelo. Ou eles são, isso é duro. Ou são como nós dois e têm... Ainda não está completamente grisalho. Algumas pessoas se enganam achando que o cabelo ainda não está completamente grisalho. Outras aceitaram isso. Mas brincadeiras à parte, a liderança, o que você chama de topo da árvore de mantenedores, certamente estamos vendo um envelhecimento significativo ali. Obviamente, com o passar do tempo, isso tem que acontecer.

[16:14] Se eu olhar cinco anos no futuro, e muitas pessoas começarão a atingir os 60 anos, e os primeiros se aproximarão dos 70 anos. Onde você vê isso indo? É um... até certo ponto, é um bom problema para se ter. Quer dizer, então a Kernel Summit foi o quê... um mês atrás, algo assim? - Três semanas. - Três semanas atrás. E foi na verdade o primeiro ano em que reagi pessoalmente ao fato de que sim, muitos de nós estamos ficando grisalhos.

[16:44] Obrigado. Mas ao mesmo tempo, parte da razão realmente é que a cúpula dos mantenedores tentamos limitá-la a cerca de 30 pessoas mais ou menos. Dessas 30 pessoas, pelo menos três estavam por aí há mais de 30 anos. Então estavam por aí desde tipo, o primeiro ano da existência do Linux, e o fato de que ainda estão por aí e ainda ativos, e ainda acabam vindo às cúpulas de mantenedores significa que sim, eles estão mais velhos e mais grisalhos, mas também significa que realmente temos uma comunidade onde as pessoas permanecem.

[17:20] Mas isso é uma faca de dois gumes. Com certeza. E é... Por exemplo, uma das coisas que gostei no lado do Rust do kernel foi que havia um mantenedor que era claramente muito mais jovem que a maioria dos mantenedores, e esse era o mantenedor do Rust. E, e, hã, podemos ver claramente que certas áreas no kernel trazem mais jovens. Tivemos uma... na cúpula dos mantenedores, tivemos essa clara divisão entre as pessoas de sistema de arquivos que eram muito cuidadosas e muito conservadoras e se importavam profundamente que seu código estivesse 100% correto porque se você tem um bug em um sistema de arquivos, os dados no seu disco podem desaparecer.

[18:13] Então essas pessoas se levam muito a sério e levam seu código muito a sério. E então você tem as pessoas de drivers que são um pouco mais, OK. Especialmente as pessoas de GPU parecem ser tipo, vale tudo. E você notou que no lado dos drivers, é muito mais fácil encontrar jovens e é tradicionalmente assim que crescemos muitos mantenedores, incluindo, quer dizer, o Greg sem cabelo.

[18:46] Peço desculpas, Greg. Você pode me bater depois. Quer dizer, minha testa está ficando maior a cada ano, então o que posso dizer? Não está longe de mim. Vamos mudar completamente de assunto e falar sobre outra coisa. Você não pode possivelmente dar uma apresentação hoje, como o Jim nos provou, sem falar sobre inteligência artificial e grandes modelos de linguagem. Hmm, eu costumo dizer que inteligência artificial é o autocorretor sob esteroides. Porque tudo o que um grande modelo de linguagem faz é prever qual é a próxima palavra mais provável que você vai usar e então extrapola a partir daí. Então, não é realmente muito inteligente.

[19:26] Obviamente, o impacto que isso tem em nossas vidas e na realidade em que vivemos é significativo. Você acha que veremos código escrito por LLM sendo submetido a você como um pull request? Estou convencido de que vai acontecer, sim. Quero dizer, e pode muito bem já estar acontecendo, talvez em menor escala, onde as pessoas realmente o usam mais como uma ajuda na escrita de código, mas é... é claramente algo em que a automação sempre ajudou as pessoas a escrever código. Quero dizer, isso não é nada novo, certo.

[20:07] código de máquina. Nem sequer escrevemos mais assembler. E agora estamos passando de C para Rust. Então eu não vejo isso como algo tão revolucionário quanto todas as notícias falam todos os dias sobre IA. Não é uma área com a qual eu obviamente-- trabalho. Ainda estou muito no nível baixo. Entrei nos kernels porque amo os detalhes de hardware de baixo nível e é por isso que ainda estou lá. Mas então você diz que espera que isso possa ajudar as pessoas a escrever código, que isso possa ajudar as pessoas a começar.

[20:42] Mas então, se olharmos para a conversa anterior e os desafios em torno de revisões de código e manutenção, você acha que os grandes modelos de linguagem chegarão ao ponto de poder nos ajudar a revisar código, de poder ajudar a manter subsistemas? Espero, espero, porque essa é certamente uma das áreas em que vejo que eles realmente podem se destacar, encontrar os bugs óbvios e estúpidos. Porque, quero dizer, quantas pessoas aqui são realmente programadoras nesta sala? - Muitas. - Um bom número. Muitos dos bugs que eu vejo, muitos dos bugs que vejo outras pessoas escreverem? Eles não são como, ah, bugs sutis. Muitos deles são apenas os bugs estúpidos com os quais você não pensou e você não precisa dessa espécie de inteligência superior para encontrá-los.

[21:33] Mas ter ferramentas que avisam-- quero dizer, temos compiladores que avisam sobre os óbvios, os realmente óbvios, mas ter LLMs que avisam sobre casos um pouco mais sutis-- casos em que ele pode simplesmente dizer: Este padrão não parece o padrão regular. Tem certeza de que é isso que você quer dizer? E a resposta pode ser: não, não era nada disso que eu queria dizer. Você encontrou um bug óbvio. Muito obrigado. Então eu realmente acho que os LLMs vão ser um grande -- você os chama depreciativamente -- Espere.

[22:10] corretores automáticos turbinados e eu realmente acho que eles são muito mais do que isso e como a maioria das pessoas trabalha é que todos nós somos. corretores automáticos turbinados até certo ponto. E eu vejo isso como uma ferramenta que pode nos ajudar a ser melhores no que fazemos. Mas eu sempre fui otimista. O todo -- Esperançoso. Esperançoso foi a palavra que você usou. Sim, sim. Útil, esperançoso e humilde. Esperançoso e humilde, esse é meu nome do meio.

[22:41] Mas -- Por outro lado, quero dizer, eu tenho sido tão otimista que 32 anos atrás, eu fui estúpido o suficiente para pensar que você pode escrever um kernel melhor do que qualquer outra pessoa. Então você tem que meio que ser um pouco-- um pouco otimista demais às vezes para fazer a diferença. Minha abordagem para a sua lente realmente tem que ser essa, ei, Isso é maravilhoso. Isso vai... Eu adoro ver o otimismo. Eu não necessariamente o compartilho. Agora muitas pessoas discordam de mim.

[23:13] Mas uma das coisas com que me preocupo em tudo isso é que vemos as alucinações. Vemos... E esse é um termo técnico para LLMs. Eles alucinam e inventam coisas. E então, quanto mais eles são colocados na posição em que farão coisas automaticamente sem um ser humano real lá para pegá-los. mais isso se torna assustador. não assustador no sentido de que eles vão dominar o mundo e não no sentido de ficção científica, mas no sentido de tantos bugs que acontecerão e que afetarão nossas vidas ou nosso código.

[23:49] Bem, eu vejo os bugs que acontecem sem eles todos os dias. Então talvez seja por isso que não estou tão preocupado. Acho que estamos fazendo isso muito bem sozinhos. E não acho que posso encerrar o tópico de IA com um destaque melhor. Vamos passar daí para o meu próximo. tópico sobre o qual eu queria falar, que é dados. O que, é claro, está muito relacionado à IA, na verdade. 30 anos atrás, quando começamos com código aberto, parecia que o código era a coisa que controlava o futuro e a capacidade de colaborar, de ter isso, como Jim descreveu, bilhões de dólares em código que criamos é o fator determinante do futuro. Isso certamente era verdade nos anos 1990.

[24:38] Se eu olhar para nossas vidas hoje, parece que são muito mais os dados que controlam nosso mundo. O que os Googles, Amazons e Apples do mundo sabem sobre nós. Então, você se envolve nas discussões sobre dados abertos? Tipo-- repetindo aquela revolução só que em outro domínio? - Não, não, então uma das coisas que mais gosto no código aberto sempre foi que posso deixar pra lá e não me importar com as coisas que não são do meu lado.

[25:11] Quero dizer, isso... Isso tem sido muito verdade dentro do kernel também, onde há ÁREAS. onde eu concentro. meu esforço pessoal muito mais do que outros. E deixo outras pessoas que mantêm esse lado se preocuparem. como redes, coisas como drivers. E o mesmo vale muito para Todos os projetos da LF. Uh... Eu posso ser um dos funcionários de maior destaque da Linux Foundation.

[25:43] Mas eu me mantenho no kernel. - Que se chama Linux Foundation. - Sim, é um ótimo nome. mas eu eu gosto do fato de que o código aberto e nem mesmo o código aberto, a noção de abertura tem se tornado muito mais amplamente aceita. E eu gosto disso particularmente porque me lembro de como era. 30 anos atrás, quando eu tinha começado este projeto e as pessoas me perguntavam: Por quê? Certo? E as pessoas diziam: Mas como você ganha dinheiro?

[26:20] Certo. E isso costumava ser uma pergunta e nunca mais aparece. Então o fato de estarmos sequer falando sobre dados abertos E ninguém sequer perguntar: "Por que você faria isso?" Eu acho que esse é o verdadeiro ponto aqui. A abertura, eu acho, até certo ponto se tornou o padrão dentro da indústria. E as pessoas meio que tomam como certo que quando você tem que ter grandes projetos, sejam eles de programação ou de dados, e você acaba tendo-os tão grandes que precisa compartilhá-los entre empresas.

[27:02] A maneira mais fácil de compartilhar é simplesmente torná-lo aberto e usar uma licença que permita compartilhamento completamente amplo, e quero dizer que isso é uma das coisas que a LF faz. Então o fato de a LF fazer dados abertos é ótimo, mas isso não significa que seja algo que eu faço. Mas eu acho que se você refletir sobre o keynote do Jim, muito do que a Linux Foundation está focada é que a colaboração além do indivíduo, além da empresa, para colaborar e fazer coisas como uma sociedade.

[27:37] tentando ser muito hiperbólico aqui. Há um papel muito grande em ter esse lugar neutro onde as pessoas podem se reunir e fazer coisas que-- - Bem, quero dizer, é literalmente por isso que estou trabalhando na Linux Foundation. porque eu me recuso a trabalhar em uma empresa Linux. porque eu não queria estar na situação em que uma empresa ou uma entidade comercial seria o lugar especial. Então eu concordo 100%. Você precisa ter um lugar neutro. E-- É por isso que dei meu nome aos links abaixo.

[28:15] Então dados abertos. O que você acha que além disso será-- a direção que essa abertura está tomando. Passamos de código aberto para dados abertos. Para onde estamos indo com isso? Onde está o--? Essa é a coisa de cinco anos, 10 anos. E eu sempre, minha resposta é sempre a mesma coisa. Sou um engenheiro lento e constante. Eu olho para o passo à minha frente. Não faço anúncios grandiosos de, é assim que o mundo será daqui a 10 anos. - Lembro que há este e-mail desse cara. Ele diz: "Ei, eu comecei este pequeno projeto divertido.

[28:54] "É só um pequeno hobby." - Bem, quero dizer, isso meio que prova o quão ruim eu sou em prever o-- Sim, é por isso que há mil pessoas nesta sala, porque você é tão ruim em planejar, eu acho. Sim, agora eu realmente acho que muitas pessoas às vezes pensam que ter um plano de longo prazo é ótimo. E eu não acho que funciona, não funciona na política. A coisa toda do planejamento de cinco anos não funcionou tão bem nessa área e eu não acho que realmente funcione muito em tecnologia. Você tem que ter meio que uma ideia de onde você gostaria de ir.

[29:33] Mas se você não olhar... Bem à sua frente, você vai apenas... tatear e nunca vai realmente chegar ao topo da montanha, certo? Você pode ter uma grande jornada em mente, mas ainda é um passo de cada vez. E isso é particularmente verdadeiro em tecnologia, onde você não pode simplesmente mudar o mundo em um grande salto. Você tem que dar todos os pequenos passos para melhorar. Você é técnico. deslize até chegar-- Bem, e já que você gosta de pensar no futuro relativamente próximo, então imaginei que vou te dar um desafio para o final da nossa conversa hoje. Então, quando o Open Source Summit voltar ao Japão no ano que vem, Onde deveria ser? Estou sugerindo Okinawa. E você? Bem, isso seria... Quero dizer, eu na verdade gosto de Tóquio. Estou aqui com minha esposa, então estivemos...

[30:33] andando por aí e visitando shopping centers estranhos, e nos divertindo muito aqui. Mas Okinawa também me parece bom. E, nessa nota, obrigado a todos. Foi bom ver vocês.