-- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
*From:* Eduardo Pereira Habkost <[EMAIL PROTECTED]> *To:* Lista de Usuarios do Slackware Linux <[EMAIL PROTECTED]> *Cc: * *Subject: * Re: [slack-users] �rvor e "oficial" d(mais longo) *Date: * Thu, 26 Jun 2003 11:50:49 -0300 Misfit! Bom rev�-la! :D E � bom ver uma resposta com alguma argumenta��o :) On Wed, Jun 25, 2003 at 08:22:28PM -0300, [EMAIL PROTECTED] </scripts/mail/Outblaze.mail?compose&misfit:linuxmail.org&a&&composeto=misfit%40linuxmail.org> wrote: > Essa � uma boa discuss�o! Com certeza. :) > > E isso � �timo! KISS, se quiser mais aplique patches. > > O Slackware n�o imp�e nada ao usu�rio, ao contr�rio de outras > distros. A liberdade tamb�m faz parte da ess�ncia do Slackware, assim > como a simplicidade. Liberdade no sentido em que o administrador tem o > total controle sobre o sistema, n�o h� nada obscuro, nem nada imposto > por terceiros. Sem amarras. �timo. Eu acho que dizer que coisas s�o "impostas" e com amarras � um pouco de exagero, mas isso � uma discuss�o totalmente diferente na qual n�o quero entrar. :) Tem coisas que, adicionando ou n�o, n�o fazem muita diferen�a, como atualiza��o de drivers, features n�o intrusivas. Isso pode ficar dispon�vel no meio de um -pre da �rvore do kernel, ir� sair s� no pr�ximo release est�vel, mas uma distribui��o pode resolver incluir, enquanto isso. > > >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 > > Um modo de integrar os trabalhos? Bem, acredito que quando um release > � feito na �rvore est�vel do kernel, ele � feito com inten��o de ser > usado em produ��o. Pelo que entendi, vc est� negando este fato. N�o, n�o estou falando que o kernel stock n�o deve ser usado em produ��o, mas em casos em que uma a��o r�pida � necess�ria, como fixes de seguran�a, que aparecem no meio do desenvolvimento de uma vers�o est�vel, n�o d� para ficar soltando releases novos s� pra isso. O kernel est� cada vez maior, e quanto mais c�digo, maior a probabilidade de aparecer um problema em algum ponto em um momento inesperado. E n�o d� para todas vez ser feita mais uma vers�o s� com isso. Sendo que � extremamente simples de: - Se voc� usa um kernel compilado por voc� mesmo, � bom manter-se informado das atualiza��es que tem aparecido, por mais r�pido que o Marcelo pudesse ter sido e liberado um 2.4.21 s� com o fix do kmod, o patch estava dispon�vel h� muito mais tempo, e com certeza voc� j� teria atualizado o sistema - Voc� usao kernel de sua distribui��o, e n�o compila o seu pr�prio kernel. Aguarde a atualiza��o de seguran�a da sua distribui��o Reconhe�o que essa � uma quest�o bem aberta, e que as opini�es podem ser diferentes. Muita gente acha que *deve* ser feito um release para corrigir coisas como esta, reconhe�o que t�m seus argumentos. Mas o ponto que tento mostrar, � que sempre fazer assim n�o funciona, al�m do fix do kmod, houveram v�rias vulnerabilidades divulgadas. A� seria necess�rio um 2.4.22, depois um 2.4.23. E o desenvolvimento do 2.4.21 que vinha, vai sendo jogado para mais tarde? Al�m do mais, "fazer um release", � apenas criar um tarball e um patch e enviar para o ftp.kernel.org. � por isso que � algo t�o pol�mico, muita gente acha s� o fato de criar um tarball "aben�oado" pelo mantenedor, mesmo com um fix *pronto* que muitas outras pessoas sabem e s�o capazes de aplicar, � essencial. Outros, como eu, acham que isso n�o faz tanta diferen�a assim, pelas raz�es que coloquei acima. E estou falando do processo de atualiza��es de seguran�a, n�o da estabilidade do sistema. O 2.4 � para ser est�vel e usado em produ��o, mas h� casos em que uma a��o r�pida � necess�ria, e ningu�m precisa de um tarball sendo enviado para o ftp.kernel.org para poder tomar essa a��o. > > >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: > > Um integrador? Mas o mantenedor n�o � aquele que *decide* o que vai > ou n�o entrar no pr�ximo release? Se � isso, ele n�o � *apenas* coisa > nenhuma, ele � grande coisa e muita gente est� aguardando quais ser�o > as *suas* decis�es. �, ele decide, sim. Mas ningu�m nunca disse que precisam ficar dependendo dele para ficar liberando fixes que est�o amplamente divulgados por a�. (�, a quest�o pol�mica do "apenas um tarball enviado para o ftp", novamente). Mas apesar disso, ele n�o � um Deus que vai fazer todas as decis�es. � uma equipe, e opini�es s�o ouvidas, e pessoas decidem em conjunto. E eu nem sei o quanto a decis�o de n�o fazer um release novo, por exemplo, foi feita apenas por ele, ou foi decidida em conjunto por v�rias pessoas. O trabalho maior dele � de integrador. Ele toma decis�es sim, mas a maior parte das decis�es vai vir ouvindo o que o resto da equipe de desenvolvedores acha. > > >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. > > Mais uma vez vc nega que o kernel "vanilla" foi feito para ser usado em > ambientes de produ��o. O Kernel do Linus sempre foi tido como um kernel > seguro e est�vel. Isso � a quebra de dogmas. � o mesmo que falei ali em cima. O kernel "vanilla" � para ser usado em produ��o, mas tem casos em que uma a��o r�pida � necess�ria e [...] [coloque a explia��o do "apenas um tarball enviado para o ftp", aqui =]. > > Quer dizer, dessa forma n�o h� um Linux que "preste", mas sim uma > "boa distribui��o Linux". O sistema depende da distribui��o, do > distribuidor... O Linux n�o foi feito para ser usado em produ��o. Se > isso � verdade, ser� um triste fato. Sim, � o ponto que falo, e que v�rios discordam: o sistema depende do distribuidor. O distribuidor � um modo de reduzir trabalho duplicado. Se todo usu�rio fosse pegar o software atualizado direto dos desenvolvedores, e se encarregasse de atualizar o mesmo e deixar funcionando no seu sistema, do mesmo jeito que estava na vers�o anterior, que pode ter certos par�metros espec�ficos, que voc� escolhe na hora de compilar, a� sim, ia ser esfor�o duplicado. > > Eu pergunto: se isso � verdade, qual o sentido de se chamar a �rvore > de est�vel? Afinal, ela n�o � confi�vel e depende de patches para se > tornar alguma coisa pr�xima a isso. Ela depende em casos inesperados que acontecem, que precisam ser corrigidos imediatamente, que s�o atualiza��es de seguran�a, que qualquer um capaz de pegar o fonte e compilar tem que ser capaz de fazer, e n�o precisa exigir uma vers�o nova. > > Se realmente quebrarem meus dogmas, est� na hora de ir acompanhar as > BSDs e OpenBes pois o Linux est� todo errado (na minha modesta opini�o). Bom, eu prefiro o Linux, mas j� h� muuuuuito tempo (bem antes de algu�m ouvir falar em 2.4), uma cr�tica frequente do pessoal dos BSDs, ao Linux, � que ele � bagun�ado e desorganizado (para os padr�es deles). E isso n�o � de hoje, e n�o � s� com rela��o ao kernel. � um efeito do modo como � feito o seu desenvolvimento: de modo altamente distribu�do. A mesma coisa que faz com que o seu desenvolvimento seja *bem* r�pido, torna certas coisas desorganizadas, no fim. De quem � a culpa? De ningu�m, ou melhor: de todo mundo, as coisas foram crescendo assim. N�o estou dizendo que isso n�o pode mudar, ou algo do tipo, s� foi um coment�rio, mesmo. > > >>> O pessoal do Debian teve que ir al�m j� que a distribui��o � multi-plataforma > > > >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. <snip> > >Para isso que existem mantenedores para cada peda�o, para eles cuidarem para > >as coisas funcionar, e integrar isso na �rvore "oficial". > > Certo, cada um faz sua parte e assim tudo � integrado na �rvore > oficial. E tudo fica bem assim. Exatamente. > > Mas, se � preciso haver um segundo integrador, ou um terceiro, j� que > a "�rvore oficial" n�o est� contando com vers�es razo�veis do kernel, > ent�o h� algum problema nos prim�rdios dessa integra��o. Portanto, a > responsabilidade � do mantenedor. Ele deveria ter integrado isso direito > no in�cio para evitar que terceiros tenham que assumir o papel que cabe > a ele. Acho que � esse o ponto. Sempre h� v�rios integradores, gente que vai pegando trabalhos de determinadas �res, e gente que tem ainda mais responsabilidade de colocar esse trabalho na �rvore principal. Basta olhar o arquivo MAINTAINERS. (-: E, � bom avisar: n�o estou dizendo que o Marcelo � perfeito, o trabalho dele sempre foi �timo, etc. S� estou tentando esclarecer e discutir algumas coisas, principalmente quanto � vis�o de como o desenvolvimento funciona, e de quem � a responsabilidade sober certas coisas. Por exemplo, o 2.4.21 demorou, mesmo, para sair, pode ser considerada uma falha do mantenedor, ser lento desse modo. O pr�prio David Miller tinha reclamado disso na linux-kernel, e parece que isso mudou, agora. ;) Cr�tica � bom, mas n�o quando n�o vira ataque e FUD. > > Quanto ao Alan Cox, acho que n�o faz muito sentido ele achar que > a distro � a respons�vel pelo kernel, no sentido em que o post dele > foi colocado nesta discuss�o. S� se baixou o "espirito corporativo" > nele. Afinal, acredito que ele lance os patches do kernel para deix�-lo da > forma que ele acha melhor, quer dizer, ele faz um "assemble" das features > as quais ele considera mais importante, ou as programa ou o que seja, para > que assim a sua �rvore do kernel tenha o que ele considerar o "melhor". E tamb�m � um modo de ele colocar certas coisas que ainda n�o foram bem testadas, enquanto a �rvore principal est� num est�gio de desenvolvimento em que n�o d� para ficar adicionando toneladas de coisas novas e n�o t�o testadas (sen�o a vers�o est�vel nunca chega, de tanta coisa). > > Bem, em mar�o surgiu essa discuss�o no LWN: http://lwn.net/Articles/26840/ > O que podemos ver � que com essa filosofia de kernels com bugs e > o descaso a respeito das necessidade s da comunidade de nada traz em > positivo. > > E porque essas compara��es com o mundo real? A Microsoft � o mundo real > hoje. E n�o � nada bonito. N�o queria trazer isso para o Linux. Dizer > "a realidade � essa" � uma opini�o bastante niilista. A id�ia por tr�s > do (GNU/)Linux � *ideol�gica*, e acredito que muitos est�o aqui por > raz�es filos�ficas e n�o apenas para fins comerciais. Isso � o valor > do Linux: a comunidade. E isso n�o deve morrer porque a "realidade" n�o > � essa. Se n�o � essa, vamos lutar para que seja! Lutar para melhorar, > pelo ideal do software livre e pela evolu��o da humanidade. Disseminar > o Linux n�o porque ele � mais barato, mas porque ele � melhor! Mas essa > � outra discuss�o... E est� mais para lista de Debians e afins... :P �, mas foi o principal ponto que quis mostrar quando respondi a mesnagem do Buick, vejo muito por a� a vis�o de que todo o trabalho com software livre � feito pela "comunidade", e que as empresas do "mundo real" que trabalham com isso n�o tem import�ncia alguma, isso quando n�o consideram que apenas sugam o trabalho feito apenas por volunt�rios. Sim, a id�ia que come�ou o Linux � ideol�gica, come�ou h� 20 anos com o Stallman, e o resto da hist�ria a gente conhece bem. Mas hoje grande parte do que foi est� sendo desenvolvido, vem de empresas, � financiado por dinheiro de empresas (governos tamb�m podem entrar nesse grupo de "empresas"), e vem do tal Mundo Real. E, sendo bom ou n�o, n�o d� para simplesmente ignorar isso. O pr�prio Linus, agora, vai poder se dedicar exclusivamente ao desenvolvimento do Linux, e por qu�? Porque a OSDL, que � formada por empresas desse tipo, vai pagar para ele fazer isso. Por isso falei de "pessoas precisam de dinheiro para comer". Se n�o tivesse ningu�m interessado em investir dinheiro nisso, n�o ia dar para o Linus, e tamb�m v�rios outros desenvolvedores que fazem muito pelo desenolvimento do Linux, dedicar tanto tempo e esfor�o para isso. Sim, o Linux ia sobreviver mesmo sem essas empresas, porque tem gente que acredita em filosofia. Sim, se n�o fosse pela filosofia, isso nem teria come�ado. Mas tamb�m, se n�o fosse o dinheiro do "mundo real", o Linux tamb�m n�o seria o que � hoje. A gente pode lutar por filosofia, mas ignorar o modo como as coisas funcionam no nosso mundo pode tornar essa luta in�til. Imagine que triste se fosse cada vez mais frequente ver mensagens como esta, em que o mantenedor do Linux Router Project deixa o projeto, justamente pelos motivos que falei: pessoas tem certas necessidades b�sicas para viver, e precisam de dinheiro para atend�-las. http://linuxrouter.org/ "I am also now semi-retired as a computer engineer. Aside from my general disgust at the computing industry and what the Internet has become, scrambling around for scrapes of work and praying for the next good money project that eventually ends suddenly in a few months, just isn't keeping food on the table. I've looked quite a bit for some stable work, but plumbers make more hourly then Sys Admins in South Florida. Either I move to California (never!) or move on. I am now reserved to do the latter. With LRP remaining an unachievable goal I don't even feel much desire to work with computers anymore." Confesso que quase d� vontade de chorar lendo algo assim. :'( > > Abra�os, Abra�os, e espero que pelo menos alguma coisa, possamos tirar dessa discuss�o :) -- Eduardo
_______________________________________________ slack-users mailing list [EMAIL PROTECTED] http://www.linuxmag.com.br/mailman/listinfo/slack-users
