On 05/22/2013 12:06 AM, Marcelo Araujo wrote: > Bom pessoal, já que o tópico mudou de ALTQ + INTEL para FreeBSD > estabilidade, gostaria de compartilhar meu ponto de vista quanto ao > 9.1-RELEASE. > > Estou trabalhando há mais de 1 ano em um produto que usa FreeBSD como base. > FreeBSD é ótimo, robusto e etc; como todos sabem. > > Agora vamos para o lado ruim, e esse lado ruim é realmente ruim mesmo. > > 1) Multirouting table e routing. > - FIB não funciona bem no FreeBSD, tive que fazer várias alterações para > fazer o FIB funcionar sem ter que iniciar daemons com setfib! Como eu > expliquei em outro email; quero que o tráfego que entra via ix0 saia via > ix0 independente da rota que tiver para a subrede na tabela FIB 0. No LINUX > isso funciona a séculos. > - Tive que modificar muita coisa para fazer isso funcionar, ficou lindo; > não submeti de volta para o FreeBSD por 2 motivos: > 1.1) NDA na empresa onde trabalho; até que bem conversadinho eles liberam. > 1.2) O desenvolvimento do FreeBSD é lento, especialmente no "SRC", > pessoal muito ocupado, existência de grupinhos e etc. > > NOTA: Um patch que enviei em 2008 para o IPFW, foi comitado alguns meses > atrás. > > 2) Routing. > - O código responsável pelo roteamento no FreeBSD é uma bagunça, não > funciona direito e é cheio de bugs. Praticamente uma caixa de pandora, > pedaços de código em tudo quanto é canto, mal documentado e etc. > - Ninguém ou quase ninguém tem coragem de abrir/tocar na "caixa de pandora". > > 3) Intel Drivers. > - As vezes no site da INTEL o driver é mais novo que no FreeBSD, e no > FreeBSD temos 4 desenvolvedores da INTEL e um deles trabalha diretamente > nos drivers de rede INTEL. > - Depois que eu enviei um patch com a atualização do driver ixgbe, o > desenvolvedor meio que deu risada, dizendo que ele é o mantenedor do driver > e que eu não precisava enviar a atualização. Minha resposta foi: -- Então > atualiza na base porra. Outros desenvolvedores também reclamaram sobre esse > problema do driver antigo na base. No final o driver foi atualizado no > CURRENT e no 9-STABLE. > > PATCH: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/176281 > > 4) Alguém sabe como o radix_mpath funciona? "EU SEI!". > - Não existe documentação para o radix_mpath, tive que ler o código para > entender como funciona. E detalhe que, não funciona como deveria, mas para > MULTIPLES ROUTING and ROUTING FAIL OVER or ROUTING LOAD BALANCE ele > funciona bem. > > 5) ALTQ. > - É uma vergonha não ter uma API genérica para que os drivers de rede usem > o ALTQ. > - IXGBE e GBE estão quebrados no 9.x por conta da falta de uma API, foram > atualizados os drivers e várias chamadas do ALTQ foram removidas e agora > são incompatíveis, pois esses novos drivers usam MULTIPLES QUEUES. > > 6) PCIe(Non-Transparent-Bridge). > - Foi inserido algumas semanas atrás esse driver pela INTEL, estou em > contato com eles há quase 1 ano, tentando ajudar, oferecendo código e etc. > Resultado, meu driver já está pronto há mais de 8 meses e eu uso DMA ao > contrário de usar memcpy() como eles(sabem que é errado) estão fazendo. > > 7) Apenas como curiosidade. > Vocês sabiam que "ifconfig <iface> 192.168.1.1/24" é errado? O que eu quero > dizer é que, para configurar um endereço IPv4, nós deveriamos fazer desta > forma "ifconfig <iface> inet 192.18.1.1/24", mas não fazemos por conta de > um bug que introduziu esta opção para nós sem ter que usar "inet" e isso > também quebrou um monte de coisa ou forçou muita gente a fazer um monte de > gambiarra em outras partes de código, especialmente na parte de roteamento. > > FreeBSD é bom? Sim, ele é! > É uma maravilha? Não, nem fodendo! > Abrir bug report e enviar patches resolve? Bom, prefiro não entrar em > detalhes!! > > """Porém, continuem enviando patches, abrindo bug reports, enviando emails > direto para os maintainers, isso ajuda bastante!!""" > > Eu vou morrer defendendo o FreeBSD, enviando patches, desenvolvendo, > fazendo o possível para melhorar o SO! Mas o FreeBSD não é aquela > maravilha, e mais do que nunca está precisando de "CARNE FRESCA" para o > time de desenvolvimento.
É por conta dessa lentidão na revisão de PRs/patches que muitas empresas acabam contratando committers pra que as coisas aconteçam de forma mais rápida. Isso é um ponto muito ruim mas acho que não existe uma solução rápida, pra isso melhorar teríamos que ter mais pessoas trabalhando no src. O que eu vejo o pessoal fazendo pra acelerar um pouco os commits é enviar o patch pra lista (-current, -stable, -net) e assim mais gente pode ver facilmente a utilidade do mesmo, o que acaba forçando o commit a acontecer mais rapidamente. -- Renato Botelho ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
