Desenvolvimento Colaborativo de Software Científico

Ou também “Colaborative Development of Scientific Software”, já para o nome do artigo.

Estou preparando uma apresentação para um curso no IFCE, e o tema é o desenvolvimento de software de forma colaborativa, ou seja, várias pessoas ao mesmo tempo trabalhando no mesmo código. Isso é padrão no desenvolvimento de código pelo mundo afora, sendo o kernel do linux o exemplo mais bem acabado desse tipo de desenvolvimento. Entretanto, o desenvolvimento de software na Academia tem outros problemas e caminhos. Por exemplo, é raríssimo um projeto de software desenvolvimento na Academia que conte com mais de um desenvolvedor do início, ou que tenha bem definido um projeto antes de começar. Outro problema bem comum no desenvolvimento de software científico é que o problema muda conforme o conhecimento sobre o problema, ou mesmo com os resultados preliminares do próprio software vão sendo produzidos, desta forma modificando o software, e assim continua. E geralmente quem desenvolve o código não é um programador treinado, mas geralmente um aluno de Iniciação Científica, Mestrado ou Doutorado, que pode ou não ter tido treinamento formal em programação ou algoritmos. Geralmente não tem treinamento, quanto mais específico. E ainda, talvez o maior problema: código legado. Um programa sem projeto, sobre um problema complexo, desenvolvido por um programador sem treinamento, e que deve ser passado para outro programador inexperiente e que ainda não é familiar com o problema científico. Isto é um GRANDE problema, sem dúvida.

O que fazer?

Minha própria formação não é de programador. Apesar de ser um bacharel em Física com ênfase em Computação, não tive nenhum treinamento formal em projeto, por exemplo. Fui treinado para resolver problemas físicos de forma eficiente usando computação, e não manter um código, técnicas de boa programação, ou documento de requisitos. Mesmo a formação em estrutura de dados deixou a desejar. E a luta contra os problemas acima nunca acaba! Mas deve existir alguma forma de se desenvolver software científico de forma mais racional. E a idéia que surgiu é tentar usar as ferramentas colaborativas. E o que são ferramentas colaborativas? São ferramentas que permitem que várias pessoas possam trabalhar ao mesmo tempo em um mesmo problema. Mas não só colaboração de código: o histórico de desenvolvimento também é importante, ao mostrar o caminho tomado e o código produzido. Além disso, a estrutura necessária para este tipo de desenvolvimento obriga que todos os programadores/cientistas integrem seus conhecimentos tanto do problema quando de código para resolver os conflitos que irão aparecer.

Não tenho a solução para os problemas acima, e na verdade, talvez algum deles nem tenham solução, pela sua própria natureza. Mas alguns dos problemas podem ser aliviados e coordenados para um aproveitamento melhor. Algumas ferramentas que podem ajudar e alguns caminhos que podem ser usados estão abaixo.

Primeiro, um sistema de controle de revisão: um sistema de controle de revisão é um sistema que permite o controle sobre o código-fonte, e a volta a qualquer ponto anterior. Existem controles de revisão para diversos tipos de dados, desde software, obviamente, até documentos legais, passando por projetos CAD e plantas. O controle de versão também permite que tais partes sejam numeradas e coordenadas. A grande utilidade de um sistema de controle de revisão em um software científico é a possibilidade de se verificar os passos anteriores do desenvolvimento do mesmo, vendo quais etapas foram feitas e em que ordem, e quais foram as mudanças na evolução das idéias e do código em si.

Outra ferramenta que pode ajudar é o uso de IDEs, que centralizam parte do desenvolvimento e permitem o uso das mesmas ferramentas e ambientes de trabalho por todos os pesquisadores. Quem já teve que lidar com makefiles ou árvores de dependências pré-históricas sabem o que é ter que fazer tudo no braço.

O uso de software de código aberto, os tais open source, também podem ajudar muito no desenvolvimento do software científico, juntamente com bibliotecas padrão, que geralmente são open source (mas não é sempre o que acontece, como o caso da Intel MKL). Existem diversos softwares open source científicos prontos, com a grande vantagem do código estar acessível, podendo ser entendido, modificado, reaproveitado e melhorado, poupando tempo e esforços – o que ocorre com frequência no software científico, que às vezes é a empreitada de um homem só (mais o seu orientador, hehe). As outras vantagens do código aberto (transparência na revisão do código, contribuição de volta para a comunidade) são também relevantes e devem ser levadas em conta, mas muitas vezes este não é o objetivo de um scisoft (acabei de inventar essa expressão, scisoft. Vamos ver se no google ela já existe… Damn. Claro que já.) As bibliotecas padrão se encaixam neste perfil.

Este post vai ter uma segunda parte…

Pequeno hack para fazer wav to mp3 usando lame

Simples assim:

for i in *.wav ; do lame –vbr-new -B 320 -q 2 ^Ci” “`basename “$i” .wav`”.mp3; done

onde o for é para pegar todos os arquivos do diretório, –vbr-new é para converter usando variable bitrate, -B é para converter em 320Kbps, e é tudo o que precisa.

As internets, o Radiohead, e as experiências únicas

Postei no Goblin sobre o projeto Rain Down, uma montagem que fizeram com imagens de celular e som da mesa de som para montar um DVD do show. Lá detalhei melhor os pontos sobre as internets e a colaboração permitida pela tecnologia. Aqui no anotherlifeform vou falar mais sobre os aspectos pessoais de uma experiência única, que depois foi remontada.

Flickr

Tenho umas fotos em um flickr: . Lá não usei o nick normal, ispmarin, e sim schrodinger_cat. Coisas de físico, vai entender.

Aceito sugestões para outros serviços de host de fotos.

FISL 10, Linux, e Lula

Post antigo, mas como prometido, aqui vai.

Fui ao FISL, em Porto Alegre. Foi um encontro muito bom, várias palestras úteis, interessantes, e algumas até divertidas. Muito mais gente que eu esperava encontrar, de longe! E ver estandes de firmas como RedHat, Qt, entre outras, foi muito impressionante. Então esse tal de software livre existe mesmo, e pessoas trabalham firmemente nele! Tanto interesse que veio gente até da Bahia para a gloriosa Porto Alegre.

E como diz o título do encontro, o FISL não era sobre propriamente o Linux, e sim sobre software livre. O linux tem uma grande proeminência nesse meio por ser um dos projetos mais antigos e mais bem sucedidos de software livre (GNU fanboys, calma). Várias outras iniciativas foram mostradas lá, com a Mozilla bem destacada, entre outras muitas mais. A palestra da Sun foi muito boa também. E claro, teve a clássica foto com o Maddog, e a uber confusão com nomes… que não vou mencionar para não queimar muito o filme.

Fato interessante: vi mais MacBooks que outro tipo de note! Como pode? Fiquei sem entender. Não conferi, mas desconfio que a grande maioria estava usando MacOS X neles.

Conheci o Peter Sunde. Assisti a palestra dele duas vezes. Coisas da organização, ficou tudo meio confuso… Não avisaram ele que eram duas palestras, e toca ele apresentar a mesma de novo. Cheio de senso de humor, realmente um cara normal. O mais impressionante foi uma pergunta feita para ele, sobre o que aconteceria se o Pirate Bay fosse vendido. Ele disse que nada mudaria, que o Pirate Bay não seria vendido, etc. Não foi pequena a surpresa quando vejo na semana que vem o Pirate Bay sendo vendido! Essa história ainda está confusa, e por enquanto o tracker deles está de pé, mas vai saber.

E também encontrei ele na festa de encerramento! Bem à vontade, na verdade. O som estava muito bom, e me emocionei quando o pessoal tocou “There, there” e todo mundo gritou “uhhuu!”! Para quem estava no show do Radiohead, foi um momento emocionante mesmo – afinal, essa foi a música onde eu vi 30000 pessoas pulando, todas juntas, sob luzes vermelhas. Cena inesquecível. Ah, detalhe: acabei subindo no palco, e videotequei! Por mais de uma hora, fiquei usando o lives, um programinha bem bacana, gerando vídeos junto com um amigo do Peter – que infelizmente não lembro mais o nome. É bem divertido, e os resultados são espetaculares!

E sim, teve o dia em que o Lula e sua patota foi no FISL. Não fui neste dia lá, preferi ir conhecer mais Porto Alegre, e valeu a pena. Adorei a Redenção, os arredores, e achei um livrinho do Battlestar Galactica, da série antiga, num sebo com muito livro de exatas e ficção científica, coisa bem rara de se achar em sebos. Bem, do Lula muito foi discutido, e ecôo as palavras do Maddog, sobre a importância do Presidente da República aparecer em um evento de software livre. Ao mesmo tempo, o esquema de segurança e os requisitos, mais a publicidade gratuita que ele coletou nas costas do movimento incomodaram bastante gente, inclusive eu. Um Presidente aparecendo em um evento desse porte manda um sinal muito forte que iniciativas de software livre são bem vistas pelo governo, e que serão apoiadas. Até que ponto isso é verdade eu desconheço, apesar de já ter ouvido falar de iniciativas governamentais nesse sentido. Em um parêntesis, ainda me frustra o tanto que a USP gasta em licenças de softwares proprietários, principalmente em Windows. Mas talvez a imagem de software livre como movimento social seja distorcer um pouco a minha idéia de software livre, onde pessoas usam seu próprio tempo e vontade apenas pelo prazer de desenvolver novas coisas. Colocar muitas camadas sociais sobre esse tipo de atividade me deixa desconfortável, por dar uma denotação política que inicialmente não estava lá. Que tem usa importância social não há dúvida, e é um aspecto importante do SL, mas para mim não deveria ser nem um dos motivos principais de se fazer SL.

Outro fato interessante: diversos jornalistas estavam cadastrados no evento. Comentei em voz alta com uma amiga que iria usar este blog para conseguir uma credencial de jornalista no próximo FISL… justo na semana em que o Supremo tirou a necessidade de diploma de jornalista. Creio que o jornalista que me direcionou palavras não muito agradáveis não estava feliz com meu comentário, até então inocente. Mas, a discussão sobre blogueiros/jornalistas não pára. Quem é jornalista? Quantos posts, ou quanta audiência você tem que conseguir em seu blog para ser considerado jornalista? Precisa ser filiado a um jornal ou outro mecanismo de média para ser jornalista? Acredito que algum controle deve haver, mas o novo papel nas novas formas de comunicação não pode ser esquecido. Blogueiro pode ser jornalista sim, e deveria ser considerado com tal, por expressar para o grande público suas opiniões, pelo menos. Mas onde essa fronteira deve ser traçada eu não sei.

Porto Alegre é fantástica. Simplemesmesmente fantástica. Conto em outro post as aventuras e desventuras nessa cidade! Com direito a mistério, intriga, brigas, e encontros muito impressionantes.

Carol, obrigado por ter me abrigado! Não podia deixar de agradecer a amiga que me ofereceu abrigo e me apresentou aos lugares bons de Porto Alegre. Abraço para todo mundo que conheci lá!

Interesses 2

Enquanto o Berkowitz me espera, pacientemente, pelo seu modelo de fraturas paralelas bidimensional, penso em interesses novamente. Postei aqui no anotherlifeform uma lista não exaustiva de interesses. Achei na época que a lista era boa, mas relendo-a vi como ela é limitada, e como ela me limita. Tudo bem, definir-se é uma missão inglória (apesar que fazer uma ficha de personagem de RPG de si mesmo deve ser um exercício de auto reflexão no mínimo interessante), mas alguma coisa deve ser definida, inclusive se quisermos mudá-la. Eis a lista, para aqueles que não querem ir para o post antigo, e note a pergunta:

Quais são meus interesses? Como se isso fosse fácil de se descrever. Como sempre, volto ao princípio socrático, e pergunto: o que é interesse? E quais são meus? Respondo a isso dizendo que interesses, e particularmente meus interesses, são coisas que me dão prazer ao fazer, que sinto que são importantes, ou que são objeto de curiosidade. Meus interesses, para a definição de quais são, se baseiam nisso.
* Computadores: Fácil. Ordenadores, organizadores, coletadores, arquivos. Guardadores de memórias e de poder, de forças. Ruminam em silêncio, esperando o momento de falar com a gente. Como não gostar? Têm um ambiente próprio, uma linguagem própria, e suas peças se encaixam, software e hardware. Ou não se encaixam, e o prazer é tentar fazê-las se encaixarem de novo, ou de outras formas. Gráficos, imagens. Ok, eu gosto de computadores.
* Ciência : Desconhecido. Fronteira. Método. A Ciência me atrai como a forma de conhecer, como um meio de se entender, como o entendimento em si. Como algo tangível e certo, ou que é puro o suficiente para se considerar certo. Poder em forma de conhecimento, onde a força deriva de idéias, conceitos, e suor. Ingrata também, onde se sofre e onde se labuta em se encaixar idéias à natureza, e a natureza em idéias. Sua coragem frente ao desconhecido, e sua tentantiva humilde de se autocorrigir são irresistíveis. Posso ainda subdividir a Ciência em diversas partes, e cada uma eu admiro de uma forma. A principal é a Física, com sua proa batendo no desconhecido, navegando entre o provável e o impossível, de forma matemática mas não infinitamente precisa. De forma geral, a Ciência ainda traz o fogo de Prometeu para todos, mesmo que às vezes traga a ira de Zeus, ou a morte entre nós mesmos. Mas nunca por si só.
* Comunicação : E de que adiantaria saber os segredos do universo e a massa do bóson de Higgs se ninguém mais pudesse saber? Ainda sim seria possível ajudar a todos? Um por vez? Dada como natural na Ciência, a comunicação deveria ser um dos objetivos últimos. Erros de comunicação, intencionais ou não, mataram mais que todas as armas juntas. Barreira intransponível entre as ilhas de homens, onde cada um é uma ilha? Em Computadores, comunicação é rede, e em rede temos a distribuição, o contato, enfim, a comunicação.
* Informação: e afinal, o que é que se comunica? Qual é a quantidade do que se comunica? Como se mede? Esta é a informação, a substância da nossa modernidade, efêmera. Me interessa pois é o que se transmite, é a consistência da Ciência, é o que se armazena. É uma unidade, talvez intangível, que pode ser categorizada, tentativamente, e analisada.
* Segurança: Talvez minha necessidade de proteção seja algo exagerada, e ainda investigo qual seria a causa. Mas ela existe, está presente na minha forma de pensar, e me atrai. Imaginar ataques se quebrando contra um rochedo é uma forma de se pensar em segurança; mas é sempre necessário lembrar que a segurança é uma relação custo-benefício – não é possível a segurança completa. O custo para tal seria infinito.
* Física: esta falei ali em cima, como uma das partes da Ciência. Com esta me sinto em casa, com esta me parece familiar, apesar de sempre estar descobrindo-a, tudo de novo.
* Tecnologia: fruto da junção da Ciência com a necessidade prática, não necessariamente nesta ordem, fascina por seus desenvolvimentos rápidos e fantásticos, suas aplicações infinitas, sua evolução ilimitada. E por ser inseparável da própria ciência, tanto como fonte de inspiração quanto causa última.
* História: saber o que aconteceu sempre pode nos ajudar a entender o que pode acontecer. Mesmo que um historiador não concorde com isso, vê-la é algo fascinante. Faz pensar na causa de sermos o que somos hoje… e que, de novo contra o credo dos historiadores, sim, ela tem uma direção, e evolui para melhor.
* Música: escuto Pictures at Exhibition, de Modest Mussorgsky. Caio de joelhos na grandeza da música, sua beleza, sua capacidade de tocar, de abrir, de se entender sem a intervenção de palavras. Sentimento de forma pura. E matemática. Rio, ao escutar o final de tal música, executada por humanos, escrita por humanos, sentida por humanos.
* Filmes: Algo que tento até hoje entender…

Cada post é um sussuro

- Qual é a razão de se ter um blog?
- E precisa de uma?

A cada conversa, escuto. Cada dúvida que pergunto, cada detalhe que ouço, cada resposta que recebo, algo clica. Talvez as pessoas não saibam, mas cada vez que ouço algo, se há um clic, aquilo grava. Faço associações. Gravo, edito, misturo. Esqueço às vezes, mas às vezes não. E com isso, o que ganho? Pequenos insights, pequenos fragmentos do pensamento dos outros, que ajudam a formar o meu. E construo uma realidade desta forma.

Penso que cada post em um blog é um sussuro, bem baixo. Em línguas diferentes, um pequeno sopro de voz, um sussuro ao vento, ao léu. Cada post. Alguns soam alto, outros nem são escutados direito, mas todos eles formam um turbilhão de sussuros, uma onda de pequenos sons. Quando tentamos escutar todos estes sons ao mesmo tempo, vindos da rede (que é um lugar, onde até entramos), somente uma cacofonia nos assalta, nos invade. Uma onda sonora tão díspar, tão misturada, que não distinguo o som de cada sussuro. Às vezes esta voz coletiva se levanta contra algo, ou se eleva em algum assunto, mas mesmo assim a cacofonia permanece, como um coral sem maestro.

Faço meus pequenos sussuros à este sopro, esperando ajudar de alguma forma, ou somente sussurando, pelo prazer de sentir os sons rolarem silenciosos, quase ronronantes, talvez egoísta. Um prazer de poder falar ao vento, gritar até, a plenos pulmões, e saber que quase ninguém vai ouvir…

Reconhecimento de Padrões 2

Associo um padrão a um estado em Física. Um estado é definido de formas diferentes para cada área da Física. Por exemplo, em Mecânica Clássica, um estado é  um conjunto de valores das variáveis de posição, momento e condições iniciais que definem completamente o sistema. Em Mecânica Quântica, um estado é o conjunto de variáveis que descreve completamente um sistema quântico e determina todas as suas observáveis. Autovetores linearmente dependentes descrevem o mesmo estado.

Um padrão portanto é associado a um estado específico, ou a um conjunto de estados que se repetem? Um estado periódico? Uma lei?

Quando um programa pode deduzir uma lei da física usando inferências, matemática e dados… poderá reconhecer outras formas do que chamamos de padrões? A definição física de estado e a associação a padrão acima funciona bem para a física, mas a palavra padrão não está presa ao seu sentido técnico.

Diferenças entre Debian e Ubuntu, em Português

Como prometido, aqui está a tradução em Português to texto do AndyC. Ele educadamente permitiu que fosse traduzido. Qualquer erro ou omissão é de minha inteira responsabilidade!

++++++++++++++++++++

Muitas diferenças: algumas grandes, algumas pequenas, mas todas podem ser significantes. Eu _NÃO_ estou falando com direito oficial pelo projeto Debian, ou mesmo o Ubuntu, de qual projeto eu também sou contribuinte.

Quando o Ubuntu começou, um de seus desenvolvedores disse para mim “se pudéssemos ter chamado de Debian para desktops, nós o teríamos feito.” Este era o foco deles naquela época; desde então ele aumentou significativamente. Mas o foco principal do Ubuntu continua sendo a experiência do usuário e um pequeno núcleo de aplicações.

Grandemente subjetivo, feito o mais distanciado quanto eu posso!

++Razões/Objetivos de Projeto++

Pacotes no Ubuntu main são altamentes polidos (trabalhados)[ed], muito bem mantidos e a Canonical/Ubuntu fazem um esforço ímpar em garantir que a experiência seja fácil para o usuário. Isto proporciona um ou mais dos seguintes custos:

++Escolha++

Falta de escolha – você ganha um cliente de email ao invés de uma escolha de vários “out of the box”, por exemplo. Escolhas são feitas para você – é um problema de suportabilidade. Debian fornece uma maior flexibilidade pelo preço de maior complexidade ou a vontade de suportar suas próprias decisões.

++Arquiteturas++

Falta de arquiteturas: se você não estiver usando Intel/AMD64 or, possivelmente, ARM/Sparc/PPC (dependendo do release) – você não pode rodar Ubuntu.  O Debian rodar em mais ou menos 11 arquiteturas significa que a) o processo às vezes é lento b) o código é debugado c) é feito de forma portável/consertos são contribuídos upstream.

++Relação Desenvolvedores/Usuários++

Canonical tem relativamente poucos desenvolvedores pagos, uma comunidade de desenvolvedores voluntários altamente motivada, uma comunidade de divulgação e um orçamento de propaganda e um número vasto de novos usuários. Isto significa que seus desenvolvedores estão em uma desvantagem numérica massiva com relação aos usuários e portanto prioridades devem ser escolhidas. Pacotes no universe/multiverse podem portanto receber menos atenção que aqueles no main do Ubuntu.

Na teoria, pelo menos, cada pacote Debian é igual e tem um mantenedor conhecido e denomeado que tem interesse Isto significa que o Debian faz o trabalho pesado de empacotar e suporte inicial para pacotes não tão comuns – isto também significa que, se eu quero suporte para o R ou CRAN, por exemplo, eu iria diretamente para o Debian por quê o mantenedor tem um interesse pessoal ou profissional em vê-lo funcionar bem como um sistema integrado.

++ Ciclos de Release++

“Nós demandamos áreas rigidamente definidas de dúvida e incertezas” – Canonical tem estas áreas porque solta releases a cada seis meses. Esta consistência tem um preço: usuários esperam novas features (características, coisas)[ed] brilhantes e superbacanas a cada release e o ciclo de desenvolvimento é bem curto mesmo. As edições com Suporte de Longa Vida (Long Term Support, LTS)[ed] são lançadas a cada 18 meses e são suportadas por três anos no desktop e cinco nas de servidor. Isto é difícil. É _muito_ difícil suportar novo hardware com as edições de longa vida. Releases “normais” podem misturar pacotes do Debian estável com o testing, instável ou até mesmo experimental (características superbacanas) mas ganham um tempo de teste bem curto.

Debian “lança quando pronto” mas depois suporta esta release até um ano após o lançamento do _próximo_ release. 22 meses para lançar o Etch, 22 meses para lançar o Lenny + 12 meses = 56 meses. Progresso lento através do testing até o release, com atualizações regulares com consertos de segurança.

++Liberdade vs. Pragmatismo++

O Ubuntu às vezes toma uma atitude pragmática para o “software que funciona” para os usuários. Eles também tem a habilidade, que o Debian não tem, de entrar em acordos comerciais com outras companhias por ex. Oracle/VMWare. [DFSG - não "licença apenas para o Debian"]. A Canonical se beneficia do idealismo do Debian, mas o fluxo não pode escoar no outro sentido

++Atualizações entre releases++

Você pode escutar muitas visões sobre isso. OPINIÃO SUBJETIVA A SEGUIR: SENTIMENTO DE DENTRO E EXPERIÊNCIA EM PARTES IGUAIS. Ubuntu é mais difícil de se atualizar limpamente entre as releases e pode ser na verdade mais rápido se reinstalar. Você certamente pode pular uma release portanto você não precisaria ir do 8.04, 8.10, 9.04, 9.10 (por exemplo). Isto é parcialmente uma consequência do ciclo de desenvolvimento curto visto acima. O Debian é _muito_ mais polido aqui /SUBJETIVO

++Sumário++

Tudo isto é bem explicado no The Official Ubuntu Book e na entrevista deMark Shuttleworth para a revista “Linux Format”. Também vale a pena ler newsgroups/fora e o planet.debian.org/planet.ubuntu.com para se apreciar melhor as abordagens semelhantes e diferentes. Debian e Ubuntu ambos tem pontos positivos: sua (algumas vezes complicada) simbiose – ambas as distribuições compartilham desenvolvedores, por exemplo, mas não necessariamente objetivos – mas o Debian ganha tanto quanto o Ubuntu se eles conseguirem consertar o maldito bug #1

Espero que ajude,

AndyC

++++++++++

E aí está. Os comentários em parêntesis com um [ed] depois foram termos que acrescentei para tentar fazer um entendimento melhor. Mantive alguns termos em inglês pelo uso corrente deles na área, ou para facilitar mesmo (como o termo release).

Por favor, enviem correções/omissões/barbaridades que eu tenha feito!

Diferenças entre Ubuntu e Debian

Lendo a lista de usuários Debian (debian-user), vi uma discussão que achei muito interessante, sobre as principais diferenças entre o Debian e o Ubuntu. O autor, AndyC, liberou o artigo para ser postado no wiki.debian.org, então reproduzo aqui o post. Leitura muito interessante, que vou tentar depois traduzir para o Português.

+++++++++++++++++++++++++++++

Post deAndrew Carter, debian-user@

Lots of differences: some big, some small but all may be significant. I
am _NOT_speaking in an official capacity for the Debian project or,
indeed, for Ubuntu to whom I’m also a contributor.

When Ubuntu first started, one of their developers said to me “If we
could have called it Debian for desktops, we would have done”. That was
their focus then: it has widened significantly now. But the core focus
for Ubuntu remains the user experience and a small core of applications.

Largely subjectively, from as far to the outside as I can get

Rationale/design goals
======================

Packages in Ubuntu main are very highly polished, very well maintained
and Canonical/Ubuntu go the extra mile to make the experience easy for
the user. That comes at one or more of several costs:

Choice
======

Lack of choice – you get one mail client rather than a choice of
several “out of the box”, for example. Choices are made for you – its an
issue of supportability. Debian offers you more flexibility at the price
of complexity or being willing to support your choices.

Architectures
=============

Lack of architectures: if you’re not on Intel/AMD64 or, possibly,
ARM/Sparc/PPC (depending on release) – you can’t run Ubuntu. Debian
running on 11 or so architectures does mean that a) the process is
sometimes slow b) the code gets debugged c) is made portable/fixes are
contributed upstream.

Developer/user ratio
====================

Canonical has relatively few paid developers, a highly motivated
volunteeer developer community, a much larger community advocacy and
marketing budget and a vast number of new users. This does
mean that their developers are massively outnumbered by their users and
priorities have to be set. Packages in universe/multiverse may therefore
receive less attention than those in main in Ubuntu.

At least in theory, every package in Debian is equal and has a known named
maintainer who takes an interest It does mean that Debian does much of
the heavy lifting of packaging and initial support for out of the way
packages – it also means that, if I want support for R and CRAN, for example,
I’d go straight to Debian because the maintainer has a personal and
professional interest for seeing it work well as an integrated system.

Release cycles
==============

“We demand rigidly defined areas of doubt and uncertainty” – Canonical
has those because it releases once every six months. This consistency
comes at a price: users expect new whizzy features with each release and
the development cycle is very short indeed. Long term support releases
happen every 18 months and are supported for three years on the
desktop/five years on the server. That’s hard. It’s _very_ hard to
support new hardware with long term releases. “Normal” releases may mix
packages from Debian stable with testing, unstable or even experimental
(whizzy features) but get only a short testing time.

Debian “releases when ready” but then supports that release until about
a year after the _next_ release. 22 months to release Etch, 22 months to
release Lenny + 12 months = 56 months. Slow moving progress through
testing to release, regular point updates with security fixes.

Freeness vs. pragmatism
=======================

Ubuntu may sometimes take a pragmatic attitude for “software that works”
for users. They also have the ability, which Debian does not, to enter
into commercial agreements for third party apps e.g. Oracle/VMWare.
[DFSG - not "licence just for Debian"]. Canonical benefits from Debian
idealism but it can’t flow the other way

Upgrades between releases
=========================

You’ll hear lots of views on this. SUBJECTIVE OPINION FOLLOWS:GUT
FEELING AND EXPERIENCE IN EQUAL PARTS. Ubuntu is harder to upgrade
cleanly between releases and it may actually be quicker to reinstall.
You certainly can’t skip a release so you’d need to do 8.04, 8.10,
9.04, 9.10 (for example). This is partly a consequence of short release
cycles above. Debian is _far_ more polished here /SUBJECTIVE

Summary
=======

All of this is very well explained by The Official Ubuntu Book and Mark
Shuttleworth’s latest interview for ?? Linux Format ?? magazine.
Its also worth reading newsgroups/fora and planet.debian.org /
planet.ubuntu.com to get a better appreciation of the similarities and
differences in approach. Debian and Ubuntu each have strengths: its a
(sometimes uneasy) symbiosis – both distributions share many of the same
developers, for example, but not necessarily end goals – but Debian
gains as much as Ubuntu if they’ll just fix their bloody bug #1

Hope this helps,

AndyC

+++++++++++