Oioi! Meio atrasado (segunda-feira, n�? no feriado eu estava meio longe)
Antes de tudo, aquele aviso padr�o: As opini�es aqui s�o *minhas* e n�o representam a empresa em que trabalho. (/me olha em volta e v� se h� lugares para se esconder das pedradas de alguns) On Fri, Jun 20, 2003 at 03:36:38PM -0200, Buick Sk wrote: <...> > > eh, al�m disto disse que trabalha o tempo todo no kernel e que a empresa em > que trabalha fica a disposi��o para arrumar o kernel o tempo que for > necess�rio.. resumidamente � a mesma coisa que dizer: > > "Na empresa ao qual trabalho somente arrumo o Kernel para a empresa e quando > estiver muito defasado o Kernel eu at� posso ter tempo de colocar algo novo" Na "empresa em que ele trabalha", todo o seu tempo � dedicado � manuten��o do kernel, *mesmo* sendo o seu sal�rio pago por tal empresa. A manuten��o do do kernel "para a empresa" � feita por outra equipe, basta verificar os changelogs dos pacotes do kernel do CL snapshot (pegue qualquer pacote em http://ftp.nl.linux.org/conectiva/snapshot/i386/RPMS.main/ e veja com 'rpm -qp --changelog'). Por favor, se n�o tem informa��es sobre como algo funciona, n�o fa�a FUD. Sobre a inclus�o de features e suporte a hardware: �, isso pode acontecer no kernel do CL, por qu�? Porque o mantenedor do kernel 2.4 n�o � um Deus, ele integra o trabalho de v�rias pessoas, de uma equipe, e nem todos os mantenedores de determinados subsistemas ir�o concordar em incluir determinadas features e suporte a hardware. Por�m os desenvolvedores de uma distribui��o podem ter um prop�sito espec�fico, e podem querer incluir coisas que n�o est�o na tal �rvore "oficial". > > Foi o mesmo fato que aconteceu com o inicio do projeto do XFree v3, quando a > maior parte dos desenvolvedores do X eram funcionarios da SuSe (isto por volta > de 1994, diversos hardwares eram suportados pelo Xfree do SuSe e n�o tinha > nada no oficial) e isto rolou muitos stress. Legal, a SuSE doava boa parte dos Recursos Humanos *pagos pela SuSE* para o desenvolvimento do XFree, e ainda isso � visto como algo ruim. > > Agora, claro que existe pessoas que realmente tiro o chapeu como o Alan Cox > que apesar de ser bancado pela RedHat n�o deixa a Real comunidade na m�o. > > traduzindo: "No fundo do tunel existe alguns que mantem a vela acessa" �, gente que recebe de uma empresa para trabalhar, tem que se sustentar, e tal empresa, interessada em contribuir para a comunidade, permite que o desenvolvedor dedique boa parte do seu tempo para contribui��es para a comunidade. Acho que � fato conhecido que pessoas precisam de dinheiro para sobreviver, comer, morar, e as pessoas prestam servi�os para empresas, para isso. Este � o mundo real. > > > > De certa forma � uma vergonha... pois depois de quase 7 anos o > > > Eu nao considero isso uma vergonha para o Patrick ou para o Slack e > > sim para o Marcelo >:P > > De certo n�o � uma vergonha para o Patrick mas sim para a comunidade... o > Slackware era tido como um dos poucos que usava o mesmo kernel existente no > kernel.org e isto mostrava o quanto a jun��o de > GNU+GPL+QT+Mozilla+BSD+etcLicensas pode oferecer um sistema est�vel e > prazeroso de usar > Se o mantenedor de uma distribui��o insiste em utilizar sempre um kernel desta �rvore, que � um modo de integrar e centralizar o trabalho feito por v�rios mantenedores, e quer jogar toda a responsabilidade de que este kernel sempre tenha todas as atualiza��es de seguran�a sobre os (no plural) mantenedores dessa �rvore, o que podemos fazer? > Claro que continuamos com nosso prazer, mas � chato saber que o Slackware > desta vez no CD Oficial n�o vem com o pacote do kernel(vem no 2 cd) pelo > simples motivo que este deixou de ser algo oficial para ser algo patcheado.... > e de certa modo duplamente vergonhoso para toda a comunidade (principalmente a > brasileira) onde o mantenedor de algo oficial parece estar incompat�vel com a > necessidade de toda a comunidade.... e ficar com quase 2meses e meio com um > kernel ao qual sabemos que tem diversos problemas de aloca��o e formas de > atacar servidores... e saber que estas falhas n�o s�o corrigidas... e lembrar > que a poucos anos atr�s qdo surgiu a primeira falha no processador pentium o > kernel Linux (oficial) foi o primeiro a ter um controle via software. Vamos pegar um exemplo: a vulnerabilidade do ptrace/kmod, que tinha um monte de gente chorando para liberar um 2.4.21 "oficial" que corrigisse isso, e deixasse o 2.4.21-pre de lado. A decis�o de n�o fazer isso n�o vem de uma pessoa s� Como eu disse, a decis�o n�o � tomada s� por uma pessoa, olha, por exemplo, a opini�o do Alan, o tal mantenedor para quem voc� tira o chap�u: http://www.ussg.iu.edu/hypermail/linux/kernel/0303.2/0266.html > > Problemas de seguran�a sempre requer o lan�amento de uma atualiza��o o mais > r�pido possivel e infelizmente desde que o Astrinho assumiu como mantenedor > n�o tem feito isto....acho que faltou ele ler a cartilha do jardim. Acho que falta entender como o processo funciona, que n�o h� um Deus onipotente que faz as decis�es, que h� v�rios mantenedores que opinam, que o mantenedor � apenas um integrador dos trabalhos, e que: A responsabilidade de manter atualiza��es de seguran�a � da distribui��o. O mantenedor upstream, seja do que for, n�o s� do kernel, n�o tem a tarefa de lan�ar mais um release de um tarball, no meio do desenvolvimento, s� por isto. Quem insiste em baixar tarball diretamente e compilar tamb�m tem que ser capaz de saber o que � aplicar uma corre��o amplamente divulgada e dispon�vel. Mais ou menos como o pr�prio Alan diz na URL ali em cima: "If you build your own kernels apply the patch, if you use vendor kernels then you can expect vendor kernel updates to appear or have already appeared." N�o estou dizendo que o Alan seja autoridade para dizer que todos devem fazer isso. Ningu�m tem, mas se o Patrick quer fazer diferente de todo o resto dos mantenedores de distribui��es, e sempre usar a tal �rvore "oficial" e nunca fazer uma atualiza��o "pr�pria", bom, a responsabilidade � do Patrick. > > > > O pessoal do Debian teve que ir al�m j� que a distribui��o � multi-plataforma > > Sobre arquiteturas diferentes, que vi um coment�rio em outro e-mail vale o mesmo sobre mantenedores de susbistemas: a responsabilidade de manter a �rvore para uma determinada arquitetura na �rvore "oficial" funcionando direitinho, � do mantenedor da arquitetura. Ou voc� acha que o mantenedor do kernel tem todas essas arquiteturas dispon�veis para compilar e testar, sempre que for fazer um release? Para isso � que existem os -preX, os -rcX, para testar esse tipo de coisa. Para isso que existem mantenedores para cada peda�o, para eles cuidarem para as coisas funcionar, e integrar isso na �rvore "oficial". Desculpem o e-mail longo, espero que algumas pessoas passem a compreender melhor como as coisas funcionam no Mundo Real, e pelo menos pensem um pouco mais antes de acreditar em alguns tipos de FUD. -- Eduardo
pgp00000.pgp
Description: PGP signature
_______________________________________________ slack-users mailing list [EMAIL PROTECTED] http://www.linuxmag.com.br/mailman/listinfo/slack-users
