Rael

Con Kolivas, um dos desenvolvedores mais ativos do kernel Linux, deixou o desenvolvimento do mesmo alguns dias atrás. O mesmo deu uma entrevista na APC Magazine, respondendo há várias perguntas, como o motivo de seu afastamento. Kolivas era um dos mais preocupados pelo desenvolvimento do Linux no desktop.

A tradução da entrevista foi feita pelo Thiago A. Silva, que gentilmente me enviou para publicá-la. Se alguém achar algum erro, ficaríamos feliz em que o mesmo seja reportado.

Todo o texto abaixo é parte da entrevista. Have fun!

________________________________________________________

Con Kolivas é um prominente desenvolvedor do kernel Linux e forte proponente desse sistema operacional no desktop. Mas recentemente ele deixou tudo para trás. Por quê?

Nessa entrevista para a APCMag.com, Con dá respostas criteriosas explorando a natureza do mercado de hardware e software, os problemas que o kernel do Linux deve superar para o desktop, e por quê apesar disso tudo ele agora está deixando tudo para trás.

Leia a seguir uma honesta avaliação do Linux, e por quê este ainda tem um longo caminho para percorrer.

Você não saberia disso vendo-o online, mas Con Kolivas trabalha diariamente como anestesista num hospital de Melbourne. O hacking do kernel Linux é so um de seus hobbies.

Apesar disso, Con é um dos mais bem conhecidos nomes no desenvolvimento do kernel Linux – e com boa razão. Seu foco em melhorar o kernel para a performance do desktop o fez ganhar uma legião de fãs, e seus patchsets para o kernel do Linux (marcados como -ck) têm tido significante impacto. Tanto que algumas de suas mudanças foram diretamente incorporadas ao kernel, e algumas de suas idéias inspiram mudanças que ainda estão ocorrendo.

Recentemente, no entanto, Con anunciou que estava deixando tudo para trás. Interessado em escutar o que o levou à mudança eu contatei Con para falar sobre as razões de sua saída, o que é preciso para ser um desenvolvedor do kernel, e o futuro como ele o enxerga.

A resposta que eu tive foi mais do que eu pechinchei – na conversação que se seguiu, Con explorou não somente porque ele deixou, mas também as mudanças que o kernel do Linux tem que enfrentar como ele as enxerga, e a exata natureza do mercado de hardware e software que levaram ao ambiente de computação que temos hoje. Se você é um usuário de Linux ou até de Windows, ele dá excelentes apontamentos.

Ao invés de quebrar as respostas de Con, estamos publicando-as como foram ditas. Então pegue um café, relaxe e leia a seguir.

APC: Como você começou a desenvolver para o Kernel do Linux, você gostou, e qual a paixão que te motiva?

Normalmente essa seria uma questão direta para responder. Porém no momento, eu tive a oportunidade de refletir sobre o que realmente me fez participar do desenvolvimento do Kernel, e eu poderei responder a pergunta de forma mais ponderada. Então se você me der a liberdade eu provavelmente acabarei respondendo todas as suas questões potenciais também. Essa será minha visão na história da computação pessoal.

Eu tive meu primeiríssimo computador há 24 anos atrás. Fui sortudo de ter me envolvido na cena da computação pessoal não muito depois que ela começou. Desde então eu assisti todo o desenvolvimento do PC, primeiramente com a excitação de não saber qual direção tomaria, e depois com antecipação, sabendo onde se dirigiria e esperando pelo desenvolvimento.

O final dos anos 80 foi uma era de ouro para a computação. Existiam muitos fabricantes diferentes entrando no mercado dos PCs e cada um deles oferecia novos e excitantes designs de hardware, funções únicas de sistemas operacionais e um enorme poder de escolha e competição. Claro, todos eles compartilhavam muitas idéias de design de hardware e software, mas na maior parte do tempo estavam desenvolvendo uma competição uns com os outros. É quase assustador relembrar que naquele tempo, na Austrália, o computador pessoal dominante em números de propriedade e compra foi o Amiga, por um período.

Qualquer pessoa que viveu a era do primeiro computador pessoal Amiga vai relembrar o quão único era seu método de computação, e para qual direção e avanço ele levou o computador caseiro. Desde então existiram muitas tentativas frustradas de ressucitar aquela excitação. Mas isso não é sobre o Amiga, porque no final das contas ele acabou sendo um fracasso por outras razões. Minha observação sobre o Amiga é que designs de hardware radicais dirigiam o desenvolvimento e conquistavam coisas que a evolução do software nos designs existentes nunca nos levariam.

Naquele tempo os computadores pessoais da IBM e compatíveis ainda eram pesados, caros, admiradas máquinas de processamento de texto DOS. Os possuidores dessas máquinas sempre colocavam, todo ano, placas de som e de vídeo diferentes, fazendo o upgrade do hardware para tentar se aproximar do que era constituído dentro de computadores Amiga e PCs Atari.

Então entra a era obscura. O desenvolvimento de computadores liderados por hardware falharam por causa do fraco marketing e desenvolvimento, além de vários outros problemas. Foi quando o software se tornou rei, e em vez de competir, todo o hardware foi vagarosamente sendo moldado de modo a dar lucro para o design de software e sistemas operacionais.

Todos nós sabemos em que se tornou o de fato sistema operacional padrão naquele tempo. Como resultado não existia mercado, seja qual for, para o hardware que não funcionava com o framework daquele sistema operacional. Enquanto um SO tomou tudo, todos os mercados de SOs e a competição falharam um atrás do outro e os fabricantes de hardware encontraram-se vendendo para um círculo gradualmente menor de software, ao invés do caminho inverso.

O hardware desde então tornou-se subserviente do sistema operacional. Isso começou mais ou menos em 1994 e ainda é verdadeiro hoje em dia, 13 anos depois. Pior ainda, todos os fabricantes de hardware foram aos poucos comprando uns aos outros, diminuindo adiante as escolhas de hardware. Então agora os fabricantes de hardware fazem versões mais rápidas ou maiores de tudo o que já foi feito antes. Nós ainda estamos plugando CPUs mais rápidas, mais RAM, HDs maiores, placas de vídeo mais rápidas e placas de som para servir ao sistema operacional. Inovação dirigida por hardware não pode mais ser assimilada pelo mercado. Não existe dinheiro nele. Não haverá mercado para isso. Computadores são chatos.

Então vem o Linux. Todos sabemos que começou como um hobby. Todos sabemos que ficou maior do que qualquer um já imaginou. Seria justo dizer que é hoje uma das mais importantes peças competidoras de software/sistemas operacionais que resta e dirige o desenvolvimento do padrão de fato – Windows. No entanto, eu acredito que ele nunca mereceu ter se tornado nisso. Se o desenvolvimento inovador dirigido por hardware e a competição de sistemas operacionais tivesse continuado, de nenhuma forma o Linux teria atraído tantos desenvolvedores fiéis e tempo para tornar-se no que é hoje. O hardware pouco mudou em todo esse tempo, PCs são absurdamente mais poderosos se comparados com o que eles eram quando o Linux deu seu primeiro boot em 1991, mas só por causa da maior velocidade do hardware, não de maior funcionalidade ou inovação.

Então que tal o PC? Bem, o PC estava 'morrendo' de acordo com todos os indícios há 20 anos atrás. Todos sabemos agora que isso é besteira e pelo futuro previsto pelo menos, esse todo envolvedor, o processamento de informações, comunicação (e criadora de frustrações) está aqui para ficar. A internet certamente fortaleceu a posição do PC.

Então o Linux foi criado para servir à computaçãp pessoal dos desktops, e o PC está aqui para ficar. Para aqueles que estavam procurando por alguma excitação e diversão usando seus computadores, o de fato sistema operacional não te entrega isso. Nós queremos consertar, nós queremos controle, queremos poder sobre tudo. Ou alternativamente nós acreditamos em alguma espécie de liberdade ou uma combinação dos anteriores. Então nós usamos Linux. Essa foi certamente a forma que eu me envolvi com o Linux. Eu queria algo para usar no meu computador desktop de casa.

De qualquer forma, o PC desktop é sujo. É cheio de entulhos. A experiência é bastante vagarosa em todas as coisas que importam. Todos nós possuímos computadores hoje que eram considerados supercomputadores 10 anos atrás. Há 10 anos atrás nós possuíamos supercomputadores de 20 anos atrás... e assim vai. Então por que diabos tudo é tão lento? Se eles são exponencialmente mais rápidos por que demora mais que nunca para nossos computadores iniciarem, para as aplicações iniciarem e tudo o mais? Claro, quando se rendem aos números puros e esmagadores eles são fantásticos (faça o encode de um vídeo e fique maravilhado). Mas no resto das coisas eles têm que ser inacreditavelmente mais vagorosos.

Computadores de hoje devem ser 1.000 vezes mais rápidos do que eram há uma década atrás, e ainda assim as coisas que importam são mais lentas.

O argumento padrão que as pessoas me dão em resposta é "mas eles fazem tão mais nesses dias que não é uma comparação justa". Bem, eles são 10 vezes mais lentos apesar de serem 1.000 vezes mais rápidos, então devem estar fazendo 10.000 vezes mais coisas. Claramente as 10.000 vezes mais coisas que fazem estão no lugar errado.

APC: Então, os problemas de performance do Linux no desktop tornaram-se uma motivação para você?

Sim. Eu comecei a pensar em melhoramentos no desktop Linux. "Certamente se eu tiver controle completo sobre todo o software, poderei acelerar as coisas," eu pensei. Tem que existir uma forma de ajustar isso, afinar aquilo, otimizar isso e conseguir mais melhorias na velocidade? Melhoras no Userspace pareciam bastante limitadas quando eu comecei no Linux. Na metade do tempo funcionavam pouco no Desktop, então tentar conseguir velocidade disso na verdade significaria que nada funcionava. O legado do UNIX era evidente. Nós estávamos moldando um sistema operacional que nunca foi feito para o Desktop e isso ia doer... um bocado.

Eventualmente os únicos cantos que notei melhoras na velocidade foram desenvolvimentos no Kernel. Nunca eram imensos, mas causaram parcamente mudanças notáveis em coisas como ligeireza, comportamento sobre CPU carregada e assim vai. O primeiro patchset que eu liberei para o público não continha nenhum código meu e foi para o kernel 2.4.18, mais ou menos em fevereiro de 2002. Eu não sabia como era o código C antes disso, nunca me tendo sido ensinada nenhuma ciência de computação.

Então eu me emperrei com aquilo por um tempo, até que o processo de desenvolvimento do kernel 2.6 estava a caminho (nós ainda estávamos no kernel 2.5 naquele tempo). Eu assisti o desenvolvimento e para ser honesto... fiquei chocado. Os nomes de todos os hackers do kernel que eu vim a respeitar e observar estavam freneticamente deslizando nesse novo e melhorado kernel e quase todo mundo estava trabalhando nesse lixo empresarial que um desktop não precisa.

Ainda pior que isso, enquanto eu obviamente gosto de ver o Linux rodar em 1.024 CPUs e 1.000 hard drives, eu detesto o fato que para implementar isso nós temos que matar performance no desktop. O que é isso? Matar performance? Sim, é isso que quero dizer.

Se numericamente quantificarmos isso com todas as quantidades mesuráveis, a performance é melhor do que nunca. Ainda assim tudo o que isso levou foi iniciar uma aplicação de áudio e admirar-se por que diabos se você respirasse nela o áudio iria saltar. Saltar! Jigabazillion bagigamaherz da CPU e nós não poderíamos tocar áudio?

Ou clicar em uma janela e deslizá-la através da tela e a mesma começaria a cuspir e gaguejar em arranques. Ou escrever um arquivo grande no disco e ver que o o cursor do mouse moveria, mas todo o restante no Desktop estaria morto e sem atualização por um minuto.

Eu senti como se estivesse chorando.

Até lembro um bug report que tentamos enviar sobre isso e um desenvolvedor disse que não poderia reproduzir o problema em sua máquina QUAD-CPU 4GB RAM com 4 discos striped RAID array... pense sobre o tipo de hardware que o usuário comum teria há quatro anos atrás. É de se maravilhar que o Desktop era um lixo?

Os desenvolvedores estavam todos desenvolvendo para algo que não era o Desktop. Todos foram empregados por grandes fabricantes que não se importavam com o Desktop (e ainda não se importam), mas os desenvolvedores querem seus últimos 1% nos benchmarks de banco de dados deles ou seja lá o que for.

O Linux ganhou. Nós éramos os maiores competidores nos mercados de servidores e banco de dados afora e todos os grandes nomes se importavam com o Linux. O dinheiro de todos esses grandes nomes estava chovendo para melhorar a performance do Linux nessas áreas.

Os usuários perderam. O PC Desktop, para qual o Linux começou a se desenvolver, caiu para as marginais. A performance, como os usuários de desktop entendem performance, se foi. Pior ainda, não havia modo de quantificar isso, e os desenvolvedores não ligariam se nós não pudéssemos provar isso. O único lugar que vi que alguma performance deveria ser ganha no desktop (o kernel) estava agora fazendo o oposto.

APC: Então o que você fez para tentar convencer os desenvolvedores do kernel da necessidade de focar os usuários finais?

Eu criei alguns benchmarks para tentar quantificar os problemas de performance do Linux no desktop. O primeiro benchmark que criei chamava-se 'Contest' (a intenção era fazer um trocadilho). Era terrivelmente complicado de usar e configurar e os resultados eram difíceis de interpretar, mas pelo menos eu tentei. E ajudou. Algumas mudanças vieram como resultado desses benchmarks, principalmente na disk I/O front. Então ainda fiquei contemplando a performance gaguejante da CPU shedulling.

Eu tive alguma experiência em fundir patches de kernels anteriores e ironicamente a maior parte deles tinham códigos ao redor da CPU scheduler. Apesar de eu nunca ter aprendido a programar, olhando para o código o mesmo eventualmente começou a fazer sentido.

Então comecei a apontar para as pessoas o que eu pensei que o problema era, olhando para aquele código particular. Depois de gritar e dizer o que eu pensava que o problema era, compreendi que poderia começar a consertar e otimizar o negócio eu mesmo.

Depois de alguns experimentos frustrados comecei a escrever algum código que ajudou... um bocado. As pessoas começaram a prestar atenção e eventualmente meu código foi incorporado. Eu nunca estava muito feliz com a forma que a CPU scheduler cuidava da interatividade, mas pelo menos agora estava usável no desktop.

Não estando feliz com a forma como o mecanismo de base trabalhava, comecei a refazer o design eu mesmo do zero, e a segunda geração do patchset -ck nasceu. Dessa vez a maior parte do código era minha. Então essa é a história de como comecei a escrever meu próprio código para o kernel do Linux.

Resumidamente, seguindo isso encontrei-me escrevendo códigos que muitos, muitos usuários de desktop acharam úteis, mas eu não tinha formas de quantificar essas mudanças. Sempre tem um elemento "Placebo" que faz a experiência do usuário final difícil de esclarecer, ou se existe um melhoramento ou não.

No entanto tentei arduamente tornar-me resistente a esse efeito "Placebo" durante anos de teste, e concluí pelo fato de meu website ter 1 milhão de sugestões que existem pessoas que concordam que de fato faz alguma diferença. Essa inabilidade de provar quantitativamente a vantagem que o -ck oferece, apesar disso, foi o que eventualmente prenunciou sua morte.

APC: Qual código foi incorporado ao kernel mainline?

Olhando para trás, enquanto o patchset foi bem conhecido, pouco do código atual acabou entrando no kernel mainline, mesmo tendo desdenhado interesse e desenvolvimento de outras pessoas naquele tempo. A maior parte que foi incluída foram mudanças na CPU scheduler para melhorar a distribuição (fairness), distribuição do user SMP, fazendo-o comportar-se bem por si mesmo, distribuição da hyperthread, e por aí vai. Existiram várias outras contribuições menores em outras áreas, como o subsistema de memória virtual, software suspend, disk I/O scheduling e bugfixes aleatórios.

A ênfase do que eu me envolvi ainda é na área que tem vários patches -ck do último release que liberei (2.6.22-ck1). Os patches restantes refletem onde eu ainda acredito que problemas massivos existam no desktop, e ironicamente, apesar de meus esforços para o contrário, os mesmos problemas parecem ser magnificados a cada ano que passa.

Parece que os desafios emergentes para o kernel do Linux no desktop nunca são enfrentados totalmente de coração por nenhum desenvolvedor de tempo integral, e apenas obtém um relance sem importância quando os problemas são tão óbvios que até mesmo aqueles na mailing list do kernel estão desejosos de reclamar sobre eles.

APC: Existiu um "pedágio" em você por esse envolvimento voluntário?

Sim. Sem dúvidas, não importando o quão pesadamente eu estivesse envolvido, eu ficaria acordado durante a noite pensando em soluções de código, eu teria o sono negado, e isso poderia ter impacto no meu trabalho e vida familiar. Eu tentei arduamente nunca comprometer essas duas coisas pela causa do desenvolvimento do kernel, mas talvez na ocasião eu tenha empurrado isso muito para frente. Eu faço um esforço para nunca me lamentar de nada que fiz, então ainda estou satisfeito com meu envolvimento até agora.

APC: Qual foi a força motriz que fez você se desligar do desenvolvimento e do patchset -ck?

Essa é uma daquelas "Eu desejaria ter uma moeda de 10 cents para toda vez que me perguntarem esse tipo de coisa".

Como a maioria das pessoas estão cientes, meu envolvimento no kernel foi motivado em três frontes, e não tem nada a ver com minha carreira nem com minha vida.

Primeiro, foi bastante divertido. Eu sempre fui um geek e gosto de passar horas em frente ao computador fazendo... bem, qualquer coisa, realmente. Então gastar tempo em algo que se tornou uma paixão para mim foi uma óbvia fonte de grande diversão.

Segundo, foi um desafio intelectual. Pareciam haver coisas que eu sempre desejei ver no kernel do Linux, e existiam assuntos que as pessoas realmente não se importavam em tentar resolver, e por aí vai. Na tentativa de confrontar eles diretamente eu estava fazendo algo que realmente não havia feito antes em termos de programação de alto nível. Eu aprendi um monte de coisas sobre design de sistemas operacionais e todas as outras coisas básicas de ciências da computação com as quais a maioria dos estudantes provavelmente estão chateados.

No entanto, tudo era novo para mim. Existem poucas (e alguns diriam zero) pesquisas novas em design de sistemas operacionais. Olhando para o Linux existe inovação na forma de tocar as coisas adiante, mas não que exista nada novo sobre os problemas que estão sendo consertados. Os mesmos assuntos sempre estiveram aí em design de hardware vs software, e toda a pesquisa foi feita. Eu vi várias pessoas me acusarem de alegar ter inventado o fair scheduling. Deixe-me clarear as coisas, eu nunca fiz uma alegação tão ridícula.

O que eu fiz foi pegar o que era conhecido e tentar aplicar para as constantes atuais do design de hardware e o framework do kernel do Linux. Enquanto a 'figura global' dos problemas e soluções já era conhecida há anos, o estreitamento do ponto onde as diferenças agudas de hardware vs software se desenvolveram não o é. A inovação está apenas na aplicação dessas idéias. Métodos acadêmicos para soluções tendem a não ser úteis no mundo real. No lado oposto, o método hacker também tende a ter desastres a longo prazo até mesmo se inicialmente mostrarem ser uma solução. Encontrar o balanço ideal entre o método hacker e não ignorar os vários anos de pesquisas acadêmicas é o que é necessário.

APC: Você assimilou o balanço corretamente?

Não. Mas me esforcei para isso. Eu acho que são poucos os desenvolvedores que conseguem. Se existe uma falha na decisão por humanos em escolher qual código vai onde vai, é impossível reconhecer aquilo (outra vez estou dizendo que não é meu código).

Terceiro, foi uma viagem de ego. Se eu melhorasse algo que me importasse, veria que muitas outras pessoas se importariam também. A razão para isso, obviamente, é que eu era de fato um usuário ordinário de PC que fingiu ser um hacker do kernel. Então sempre que eu fazia melhorias que afetavam os usuários de desktop, muitas pessoas se importavam com elas. Eu lembro que um hacker do kernel que eu respeitava bastante fez uma piada sobre meus "fãs" e perguntou como ele poderia atrair uma multidão. Ele contribuiu possivelmente com 1000 vezes mais linhas de código para o kernel do Linux que eu, e ainda assim eu tinha "seguidores".

Eu apenas atraí isso porque hackeei coisas com as quais me importava. E os usuários confirmaram isso. As únicas coisas que me fizeram continuar o desenvolvimento ao longo de vários anos foram os agradecimentos que recebi dos usuários do patchset -ck.

Então, eu ainda não respondi sua pergunta sobre o que me fez parar o desenvolvimento do kernel, respondi? Acho que explicar minhas motivações ajudaria a dizer por quê parei.

As respostas dos usuários ainda estavam aí. Se qualquer outra coisa, os usuários tinham mais voz que nunca enquanto eu estava anunciando minha saída do desenvolvimento do kernel.

O desafio intelectual? Bem, isso ainda existia, claro.

A diversão? Sim, isso foi o que morreu. Deixou de ser divertido. No meu anúncio via e-mail, agora bastante público, informando que eu estava caindo fora, expliquei isso resumidamente. O patchset -ck foi por um bom tempo um objeto sem importância, fora do pátio dos refletores principais para meus experimentos. Enquanto o escopo das mudanças aumentou, as melhorias tornaram-se drásticas e foram mais agudamente notadas. Isso levou à mais e mais pessoas me perguntando quando as mudanças seriam fundidas ao mainline. Quando o número de pedidos cresceu, minha resolução para não ser envolvido no mainline diminuiu. Então eu ocasionalmente postei patches como exemplos para a mailing list do kernel. Isso gerou mais interesse e pedidos para eu me envolver com o mainline. Então eu tentei.

Você perguntou antes quais patches -ck se incorporaram ao mainline e eu listei um monte de pequenos patches aleatórios. A magnitude de mudanças nos patches que eu não me envolvi vai bem além dos que eu me envolvi.

APC: Houve algo que foi a "última tacada" para você?

Minha primeira grande rejeição foi o staircase CPU scheduler. Provou-se que era bem melhor em interatividade que o mainline CPU scheduler, mas ultimamente, assim como o mainline CPU scheduler, ele teve casos menores que mostraram que não era perfeito. Naquele tempo, enquanto eu ainda estava o desenvolvendo, a atenção desviou-se do CPU scheduler. A razão dada por Andrew Morton (o mantenedor e segunda e última porta de entrada para o kernel mainline) naquele tempo foi que o kernel tinha assuntos mais urgentes e bugs para tratar.

Claro que tinha. Tinha montes de subsistemas sendo repetidamente reescritos, e era uma quebradeira sem fim. E reescrever subsistemas que funcionam e quebrá-los é bem mais importante que algo que deve melhorar o desktop, certo? Oops, um pouco da minha amargura deslizou aqui. Eu tentarei deixar a emoção de lado e apenas contar o resto da história da forma mais objetiva que puder.

O maior problema foi que simplesmente não existia um modo convincente de provar que o staircase era melhor no desktop. Relatórios de usuários não eram o bastante. Não tinha benchmark algum. Não tinha uma forma de provar que era melhor, e os relatórios de usuários, se algo chateou os mantenedores do kernel, favoreciam a sua falta de objetividade. Eu até tentei escrever um benchmark chamado "Interbench". Note que interatividade não é o mesmo que responsividade (eu tenho um pequeno sumário da diferença, como a vejo, com o código Interbench). Esse código era bem melhor que o Contest, mas mesmo eu podendo demonstrar vantagem com meu scheduler no Interbench, a magnitude de diferenças era difícil senão impossível de extrair baseada nos números brutos gerados pelo Interbench.

Com uma carga de ajuda de William Lee Irwin III (que escreveu a arquitetura principal) eu postei um framework de CPU scheduler plugável, que permitiria incluir no kernel tantos CPU schedulers quanto fossem desejados e escolher na hora do boot qual deles rodar. Eu planejei extender isso para uma seleção no runtime também. Isso se parece bastante com o framework I/O scheduler modular plugável que o kernel do Linux tem atualmente. Foi prontamente recusado por Linus e Ingo (que é o mantenedor do CPU scheduler) por levar à especialização dos CPU schedulers e eles dois preferiram que existisse apenas um CPU scheduler que fosse bom em tudo. Acho que você pode dizer que o CPU scheduller é um esmagador que nozes, e nós, como usuários de desktop, o usamos para esmagar nozes, e eles não queriam que nós escrevêssemos quebradores de nozes para o kernel.

O propósito do Plugsched era simplesmente prover um modo sem suturas para o staircase CPU scheduler ser integrado no kernel mainline. Não me senti confiante sobre a presença de CPU schedulers plugáveis, mas muitas pessoas ainda se sentem e o código ainda é mantido hoje principalmente por Peter Williams.

Junto veio a swap prefetch. Gastei um monte de tempo mantendo e melhorando isso. Foi fundido ao -mm kernel 18 meses atrás e eu o estive apoiando desde então. Andrew, até hoje, não está convencido que isso ajuda em alguma coisa e que isso 'deve' ter consequências negativas em outro lugar. Nenhum bug report ou reclamação de performance esteve por vir nos últimos 9 meses. Eu até escrevi um benchmark que mostrou como funcionava, e consegui até mesmo quantificar! Num hilário retorno Linus me perguntou offlist 'sim, mas isso realmente ajuda?'. Bem, relatórios de usuários e benchmarks não eram o bastante... ainda está incerto no momento mas eles não terão escolha para jogá-lo fora sem que alguém esteja mantendo.

Finalmente o prego no caixão. O Staircase Deadline CPU Scheduler. Inicialmente começando como um projeto paralelo do Staircase CPU Scheduler, eu logo notei que era possível ter excelente interatividade enquanto consertava os terríveis problemas de distribuição (fairness) que um design não distribuído (unfair) tinha. Além do mais, ele de fato melhorou assuntos de interatividade em outros lugares que acabaram sendo problemas de distribuição, e a distribuição é obviamente superior aos servidores e ambientes multi-usuário.

Um monte de usuários e até desenvolvedores do kernel acharam que muitas longas e duradouras reclamações com o mainline e outros schedulers foram consertadas por esse código e praticamente me imploraram para empurrá-lo para o mainline, e outro usuário exigiu que Linus fundisse-o o mais rápido possível como um bugfix. Então eu apoiei o código e consertei-o enquanto problemas foram surgindo, juntamente com muitos bugfixes e melhorias ao longo do caminho.

Então cheguei a um beco sem saída. Um usuário com bastante voz notou que o comportamento não distribuído (unfair) no scheduler mainline era algo que ele veio a antecipar. Uma guerra de flames aconteceu nesse tempo, porque para consertar 100% dos problemas com o CPU scheduler nós tivemos que sacrificar a interatividade em alguns workloads. Não era uma perda dramática de interatividade, mas ela definitivamente estava lá. Ao invés de usar 'bom' para proporcionar o CPU de acordo com o lugar que usuário disse que o sistema operacional estaria, o usuário acreditou que era responsabilidade do kernel adivinhar. Como segue, é um fato que 'adivinhar' significa que não importa o quão duramente nem o quão inteligentemente você faça a CPU scheduler, ela vai dar errado algumas horas. Por mais que se tente adivinhar, piores vão ser os casos menos importantes de mal comportamento.

A opção é sufocar o adivinhamento, ou não adivinhar. A primeira opção significa que você tem uma CPU scheduler que é difícil de modelar, e o comportamento é certo 95% do tempo, tendo fluxo e refluxo na medição de CPU e latência. A última opção significa que não existe adivinhação e o comportamento é correto 100% do tempo... só dá o que você diz que deve dar. Parecia tão absurdamente claro para mim, dado que a interatividade na maior parte do tempo era melhor com o método "fair", e ainda assim os mantenedores exigiram que eu endereçasse isso como um problema com o novo design. Eu neguei. Insisti que nós tínhamos que abrir mão de uma pequena quantia para ganhar tremendamente mais. Um scheduler que era determinístico e previsível e ainda assim interativo é uma opção bem melhor a longo prazo do que o método "hack depois de hack" que estávamos mantendo.

Então fiquei doente. Um deslocamento no meu pescoço ditou que eu deveria ficar deitado de costas por mais ou menos 6 meses. Sim, o desenvolvimento do kernel contribuiu para esse problema. Então eu fui medicado no globo ocular e passei a maior parte dos dias e noites deitado... não tendo nada para pensar, a não ser cozinhar o kernel. Sempre que possível eu voltava ao PC para tentar apoiar o código que eu joguei afora. Eu neguei insistir (budge) no aspecto do equilíbrio (fairness), e continuei tendo isso jogado na minha cara como uma falha inconsertável no design.

Então um dia presumivelmente Ingo decidiu que era uma boa idéia, o caminho a se seguir e... escreveu seu próprio design de framework justo-interativo de scheduling... e teve ajuda de código da pessoa que negou aceitar um comportamento "fair" na minha guerra de flames.

Então eu tive um monte de tempo deitado de costas para refletir o que eu estava fazendo e por quê, e se eu estava caminhando para me lamentar disso daquele ponto em diante. Eu decidi completar o trabalho do Staircase Deadline para ter certeza que era uma referência para comparação, em vez de ter o novo código de CPU scheduler do mantenedor comparado ao velho e pesado scheduler. Então eu desisti para sempre.

APC: Os egos dos desenvolvedores são um problema no desenvolvimento open source em geral?

Eu acho que qualquer problema com qualquer modelo de desenvolvimento tem múltiplos fatores, e ultimamente, são humanos que fazem decisões. Eu não vou comentar sobre os humanos em si.

Se existe qualquer grande problema com o desenvolvimento do kernel Linux é a completa falta de participação dos usuários comuns no processo de desenvolvimento. Você sabe, aqueles que constituem 99,9% da base de usuários do Linux.

A mailing list do kernel é o meio de comunicar-se com os desenvolvedores. Colocando a assertativa docemente, a mailing list do kernel Linux (lkml) é um fórum amedrontador, quando as pessoas se aventuram a postar. A maior parte das pessoas ficam absolutamente apavoradas de postar na lista, temendo que sejam incendiadas por sua inexperiência, por um bug report inapropriado, serem acusadas de estúpidas ou seja lá o que for. E na maior parte do tempo eles estão absolutamente certos. Não existe forma amigável de comunicação com as questões dos usuários comuns que são relacionadas ao kernel. Sim, claro que os desenvolvedores do kernel gostam de diversão, pessoas amigáveis e felizes. Veja uma entrevista com o Linus e preste atenção na forma como ele se encara.

Eu acho que os desenvolvedores do kernel em sua maioria não têm a mínima idéia do quanto os problemas são grandes na área do userspace. Apenas uma brava minoria fica contente em postar para a lkml, e eu continuo tendo usuários que entram em contato pelo IRC, pessoalmente ou por minha própria mailing list dizendo quais são seus problemas. E eles até se tornam exitantes quanto a mim, apesar de eu nunca ter me visto como um desenvolvedor real do kernel.

Pesque nos fórums normais de suporte (o que eu fiz para usuários do Gentoo como um meio de encontrar bug reports frequentes, porque os usuários estavam com medo de me contar) e veja quantas questões óbvias relacionadas ao kernel existem. Eu adoraria pedir a eles todos para floodar a lkml de surpresa com seus relatórios, boots falhos com vários kernels, hardwares parando de funcionar repentinamente, desaparecimento de memória, problemas com o software suspend e seus sacos explodidos pelo laptop, e assim vai.

E aí estão todos os óbvios bug reports. Eles tem medo de mencioná-los. O quão amedrontador você acha que é dizer "minhas tabs do firefox abrem mais lentamente desde do último upgrade do CPU scheduler"? Em contraste, os usuários de enterprise são o oposto. Só assista a cada release do kernel e veja o quão rapidamente algum "$bullshit_benchmark é reduzido a 1% com o patch $Y" é reportado. Veja também o quão rapidamente eles atendem a isso.

APC: O que você está fazendo no seu tempo vago agora, e quais os futuros projetos que você têm planejados?

Eu tinha alguns brinquedos de userspace que estava experimentando (ferramentas de compressão, encoding de video/ferramentas de conversão e algumas outras) que eu pensei que voltaria a mexer. Mas olhar para qualquer código me dá um gosto ruim na boca, então isto não está mais acontecendo.

Minha paixão atual é aprender japonês. É divertido, é um desafio intelectual imenso, vai me permitir eventualmente entender sua linguagem nativa (histórias curtas, cinema, mangá e anime) e vem sem cordas incluídas. Eu nunca soube realmente qual hobby que vou terminar adotando, mas sempre torno-me completamente absorto em qualquer coisa que seja.