[firebase-br] Curiosidade. Firebird 2.5 x 3.0

[Carlos H. Cantu]

MF> Exatamente esta primeira Implicação que me funde a cuca. Na minha
MF> humilde opinião este nível de granularidade era o que deveria ser
MF> de se esperar se for SMP

Podemos "achar" muita coisa, a questão é que na vida real, estamos
limitados por diversos fatores, entre eles falta de "mão de obra"
qualificada, sistemas legados, compatibilidade, etc. Em suma,
estão fazendo o que dá pra fazer. Se houver demanda e recursos
suficientes pra se implementar essa ou aquela "feature", com ctz será
implementada no futuro.

MF> Houve uma resposta ao primeiro teste TPC da IBSurgeon.

O testes da IBSurgeon foram feitos em etapas, e pelo que lembro,
somente o último foi referente ao desempenho em máquinas com múltiplos
cores. Não acredito que tenha havido qualquer tipo de favorecimento
proposital, e até onde eu lembro, os testes com o IB foram
"inconclusivos"... em determinadas situações ele era melhor, em outras
não.

MF> Verdade mas ao custo de agregar muito mais hardware (memória) para
MF> suportar a quantidade de conexões. Escalabilidade pode se referir a
MF> várias situações, no caso me refiro (Quantidade de conexões X Espaço
MF> de memória física )

Já foi a época onde memória era cara e portanto fator limitante ;)

MF> Isso dá uma abertura para um ótimo debate, senão vejamos, todas as
MF> arquiteturas deixarem de existir no futuro você disse e logo após
MF> unificando tudo numa só, sua um pouco contraditório Carlos!

Desculpe se não fui claro, no Firebird 3 vc poderá configurar o
Firebird para rodar como classic em um determinado banco de dados,
como superserver em outro, e assim por diante, sem a necessidade de
ter múltiplas instalações do FB. Ou seja, a configuração será "por
banco de dados".

MF> E logo após você diz que no FB 3 teremos um modelo com as vantagens do
MF> Super Classic, Mas que vantagens são essas cristo? se o FB 3 vai ser
MF> um aprimoramento do Super Server ?

A vantagem do SC é a escalabilidade e o menor consumo de recursos em
relação ao classic.

MF> Eu imagino que a idéia na cabeça dos desenvolvedores seja comparar no
MF> futuro as duas arquiteturas 2.5 e 3.0 ver qual se sobressai em
MF> performance em ambientes multi-processados, quem economiza mais
MF> recursos além do quê, performance não é tudo ainda que o foco seja
MF> tirar proveito das arquiteturas atuais de processadores e sistemas
MF> operacionais que tirem proveito deles.

Vc pode perguntar isso na fb-devel, ao invés de imaginar ;-)


MF> Sei muito bem. O problema que me refiro é a restrição imposta.
MF> Compreendo que o time de desenvolvedores é menor, faltam recursos de
MF> se ter hardware rodando outros sabores de Unix e tempo para portar mas
MF> o que eu quero dizer aí é que o firebird peca por excluir outros U*IX
MF> Livres no mínimo.

Quem peca é a comunidade, ou pelo menos as pessoas que precisam usar o
FB nesses SOs, mas que não participam do projeto para disponibilizar o FB neles.

MF> Conversando com o Jim Starkey uma vez ele falou que um dos objetivos
MF> do Vulcan era a independência de Compilador C++ evitar usar recursos
MF> muitos esotéricos suportados somente pelo GCC/G++ e MSVCC para não
MF> esbarrarem com problemas com cpompiladores de outros sistemas Ex: Sun
MF> Forte C++ e não ter dor de cabeça para portar pro Solaris em
MF> arquitetura SPARC

Isso é Utopia. O próprio Java, que em teoria deveria rodar o mesmo
programa em qualquer SO, impõe "particularidades" de código para que
isso aconteça. Eu já fico pasmo do Firebird, com uma única base de
código, ser compilado em tantos SOs e plataformas diferentes.

MF> Não carlos, as partes dos fontes referente a build nessa e outras
MF> arquiteturas simplesmente foram removidas !!!

Removidas porque não eram usadas, ou não havia demanda suficiente para
mantê-las. De que adianta deixar código que não servirá pra nada? Só
complica a manutenção. Nada é removido sem antes haver uma discussão
pública na lista fb-devel. Eu dúvido que removeriam algo se alguém se
manifestasse dizendo que dependia daquilo.

MF> Verdade e só que você encontra muita resistência em encontrar um
MF> conjunto de makefiles que me ajudem a dar um build digamos no UnixWare
MF> já que o citamos aí, mesmo se eu pegar os headerfiles e o resto do
MF> fonte necessário para dar um build do Firebird no Unixware
MF> Além do quê, Carlos Henrique NÃO é simples questão de dizer que
MF> deveria suportar isso ou aquilo o problema é que havia esse suporte
MF> estava lá e simplesmente foi removido e é quase impossível
MF> reintroduzir esse port denovo infelizmente :-(  entendeu o que eu quis
MF> dizer?

Eu entendo que as pessoas sempre querem a coisa de forma mastigada:
pegar o código, dar um build e ter o binário compilado. Mas pra que
isso aconteça, como eu já disse, é necessário que haja um "Cristo" que
coloque a mão na massa. Só reclamar não adianta. O projeto tem
escassez de recursos, e portanto, quer você goste ou não, continuarão
focando onde a demanda justifique. Se o suporte a outros SOs ou
Distros é importante para você, fique a vontade para contribuir para
mantê-las. Não é fácil, mas acredito que sempre que precisar algum
desenvolvedor estará disposto a esclarecer suas dúvidas.


MF> A resistência eu penso é a manutenibilidade da coisa. Por exemplo o
MF> Firebird da suporte para HP-UX mas somente uma das últimas versões do
MF> HP-UX usa threads padrão posix (Antes a HP usava um sistema de threads
MF> proprietária pro Unix dela) então no source tree do firebird vc
MF> encontra X interfaces de threads, Posix, Windows, e X implementações
MF> para outros sistemas que diferem. É meio bagunçado deveria haver uma
MF> interface única para caa implementação acredito que as coisas estejam
MF> indo para este rumo eu vi o que o Dmitry Yemanov separou muitas
MF> chamadas de API em subdiretórios pelo menos eram dois umm Windows e
MF> Outro Unix

Bagunçado era o código do InterBase 6. As coisas estão muito melhores
agora. Obviamente ainda há o que melhorar, mas fizeram milagres com o
que a Borland "jogou" no sourceforge.

Creio que esperar que o Firebird suporte todos os tipos de sistemas
de threads e sistemas operacionais é utopia. Nem o Firebird, nem
qualquer outro banco de dados. O fato é: haverá suporte para o que
houver demanda e gente disposta a implementa-lo. O Firebird 1
suportava o Sinixz - eu nunca, em toda a minha vida - encontrei uma
pessoa que tivesse utilizado isso. Agora eu pergunto? Compensaria
manter a compatibilidade com uma coisa que "ninguém" usa, só pra ficar
"bonito na fita"? Ou seria melhor pegar as horas que seriam gastas com
isso e aplicar em coisa mais urgentes e úteis para a maioria?


[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br