| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Desculpem o amadorismo, mas quais as grandes diferenças entre o freeBDS e o netBSD?
Será apenas que este último corre em mais plataformas e o primeiro é mais rápido a servir web?
Um abraço.
David
|
| | | | | | É mais uma questão de filosofia mas sim. A prioridade do FreeBSD é fazer um sistema Unix com elevada performance e fiabilidade para algumas arquitecturas, a do NetBSD é ser o mais portável possivel.
|
| | | | Para mim, essas "prioridades" estão desactualizadas. A questão já não é propriamente o foco principal, mas sim o que realmente se passa em todo o sistema operativo.
|
| | | | Pois, mas isso é no Linux, que tem uma base de contribuições gigantesca e aberta. Nos BSDs já não é assim, as equipas são normalmente mais pequenas e fechadas.
--
Carlos Rodrigues
|
| | | | @CrLf: Sinceramente não percebi o que é que uma equipa de desenvolvimento mais coesa (nos BSDs mas também no Gnome, no KDE, no Kernel Linux, no PostgreSQL, até certo ponto no Debian) têm a ver com isto. Não só só os BSDs que têm equipas coesas.
Mas o FreeBSD está-se a perder um pouco, pelo menos nas 5.x : as releases atrasaram-se porque quiseram entulhar-se de features e a performance saiu prejudicada. Daí o fork do Dragonfly.
Mas o NetBSD 2.0 têm melhor performance do que o FreeBSD 5.x, pleo feedback que tenho visto. E como o Dragonfly ainda é novito o NetBSD 2.0 é que está a ganhar a atenção toda :)
O NetBSD é espectacular em termos de OS design: procura por pkgsrc e por RCng.
Bruno Henriques
|
| | | | | Mas o FreeBSD está-se a perder um pouco, pelo menos nas 5.x : as releases atrasaram-se porque quiseram entulhar-se de features e a performance saiu prejudicada. Daí o fork do Dragonfly. As releases do 5.x não se atrasaram. O que foi protelado foi a passagem do branch stable para a release 5.x. Esse atraso não se deveu às features, mas sim à reescrita/reestruturação do kernel. O fork do DragonFly também nada tem que ver com features, mas com visões diferentes de como resolver os mesmos problemas. Em termos de performance, o 5.3 bate o 4.10 em vários sectores, desde o roteamento de pacotes, sistemas SMP, programas thread based e em alguns casos até na utilização de dispositivos de armazenamento em massa. Quanto ao NetBSD, infelizmente não tenho tido grande oportunidade de o usar em ambientes de produção; pelo que tenho lido é uma óptima escolha para aplicações que façam uso intensivo de networking e não só.
|
| | | | Quanto ao NetBSD, infelizmente não tenho tido grande oportunidade de o usar em ambientes de produção; pelo que tenho lido é uma óptima escolha para aplicações que façam uso intensivo de networking e não só.
Se já tiveres usado fotocopiadoras/impressoras da Ricoh, talvez já o tenhas usado. Pelo menos os modelos Afício 700 e 1060 usam NetBSD.
--
Carlos Rodrigues
|
| | | | Dificilmente consigo testar a performance, robustez e flexibilidade do NetBSD numa fotocopiadora ou impressora, mas por acaso não sabia dessa, mas sempre assumi que existem uma miríade de produtos para os mais diversos fins que usam netBSD (ou qualquer outro BSD), dada a flexibilidade da licença em aplicações comerciais e a robustez do sistema.
|
| | | | Sinceramente não percebi o que é que uma equipa de desenvolvimento mais coesa (nos BSDs mas também no Gnome, no KDE, no Kernel Linux, no PostgreSQL, até certo ponto no Debian) têm a ver com isto. Não só só os BSDs que têm equipas coesas.
O que tu chamas de coesão, eu chamo de elitismo. E não é nada semelhante ao GNOME, KDE ou ao kernel do Linux.
É óbvio que existe sempre um grupo de pessoas que é mais central do que outras, mas a abertura de qualquer um destes projectos está muito para além de qualquer BSD.
O que tu podias ter usado como comparação era o XFree86. Mas ambos sabemos porque não o fizeste. O que se passou com este projecto é aquilo que se vem passando com os BSDs desde tempos imemoriais. Só que neste caso o fork foi na direcção de uma gestão mais parecida com um GNOME ou KDE e simplesmente deixou o original à morte.
Quanto ao PostgreSQL, é um projecto muito mais pequeno, e muito menos abrangente do que um SO. Portanto é natural que seja mais fechado. Mas não me parece que seja muito elitista, nunca ouvi a palavra fork mencionada em relação a ele, nem sequer remotamente.
Mas pronto, já fui puxado para a guerra santa dos BSDs. E eu nem sequer tenho nada contra eles (muito pelo contrário), apenas contra o seu método de gestão. Mas mesmo aí não tenho grandes críticas a fazer, só não me venham dizer que é possível uma abrangência semelhante à do Linux com uma gestão elitista.
--
Carlos Rodrigues
|
| | | | Discordo. Não percebo o que queres dizer com elitismo. Qualquer pessoa em qualquer ponto do globo pode mandar um problem report com o fix ou sem ele tanto para *BSD, como para Linux, como para KDE. Automaticamente, essa pessoa torna-se parte de uma comunidade. A questão de ter CVS commit access basicamente serve como método de confiança. Felizmente, a questão é muito mais complexa do que da forma como tu a expões: se algo permanece como está, não é por perguiça ou por anti-mudança, existem razões que são discutidas na mailing list porque é que certa feature não se muda. E sim, a abertura de um projecto depende imenso de certos objectivos do mesmo.
|
| | | | A abertura não se resume ao acesso ao CVS. É tudo uma questão de atitude.
Se a atitude do pessoal dos BSDs é assim tão aberta, como se justifica o forking constante em projectos que poderiam muito bem manter-se como diferentes faces de um único BSD?
--
Carlos Rodrigues
|
| | | | forking constante ? desculpa mas, omg ?
tipo,,,tipo,,, e com que coerencia é que dizes isso sem olhar para o linux (os biliões de distros de forks de forks de forks de forks de distros dizem alguma coisa...)? se há coisa que o BSD é é coeso, especialmente quando comparado com o linux.
mas também entrar aqui com comparações entre linux e BSD é um bocado inutil, visto que o licenciamento é diferente e isso só por si é fucral em relação aos moldes em que a equipa de desenvolvimento se relaciona com o mundo em geral.
--
patrocionado por: Kmos, o criminoso! |
| | | | | Não consigo ver a relação entre o licenciamento e a abertura do desenvolvimento. Importas-te de explicitar? No que diz respeiro a forks, sou da opinião que o software Livre™ tende a divergir. Nos *BSD verfica-se no core do sistema (embora também haja pelo menos uma distribuição comercial de FreeBSD), no Linux parece ser ao nivel das distribuições. Também podemos contar os clones de VI, o Emacs e XEmacs, etc, etc.
Contudo, a situação das distribuições de Linux tem, a meu ver, uma diferença substancial das variedades de BSD. As distribuições de Linux, quando pegam num software que já existe e o alteram, tendem a contribuir essas alterações para a base comum. Seja o kernel, o GNOME, o KDE, etc..
Não me parece que muitas features do OpenBSD tenham sido integradas no NetBSD.
|
| | | | | As distribuições de Linux, quando pegam num software que já existe e o alteram, tendem a contribuir essas alterações para a base comum. Em projectos diferentes com objectivos bem definidos, isso é mais contraprodutivo que produtivo. O facto de teres diversas fontes que modificam o código de maneira diferente e tendo em vista aplicações diferentes em muitos casos não contribui nada para o melhoramento do projecto base. Não me parece que muitas features do OpenBSD tenham sido integradas no NetBSD. Bem, se ignorarmos o facto de alguns dos developers do OpenBSD também serem developers do NetBSD (e que é normal o backport para o OpenBSD de modificações no NetBSD), surgem-me assim de repente algumas features, como OpenSSH, PF, ALTQ, Systrace, e eventualmente os NO-EXEC mappings.
|
| | | | «Não consigo ver a relação entre o licenciamento e a abertura do desenvolvimento. Importas-te de explicitar?»
Importo-me. não tenho "paxorra" para guerras de licenças, prefiro retirar o que disse a ir por esses caminhos.
«Não me parece que muitas features do OpenBSD tenham sido integradas no NetBSD.»
bom, então decididamente não estás informado :)
há N código, como explicitou o Ancestor no post anterior a este meu post, que é backported de netbsd para openbsd e vice-versa.
Isto é mais frequente entre NetBSD e OpenBSD mas também acontece entre FreeBSD e os demais.
«As distribuições de Linux, quando pegam num software que já existe e o alteram, tendem a contribuir essas alterações para a base comum.»
Bom isso agora tanto é relativo como tem a sua piada, porque falas de uma base comum que pura e simplesmente não existe :) alem do kernel e da presença de umas userland tools mais utilizadas, de distro pra distro pouco ou nada se mantem igual. a não ser que compares um fork com a distro de onde proveio...
--
patrocionado por: Kmos, o criminoso! |
| | | | | Se não se importam, vou responder aos dois aqui. O NetBSD e o OpenBSD têm uma origem e pessoas em comum. Portanto, é natural que tanto código como ideias de um seja aproveitado para o outro.
Mas até o Linux tem coisas aproveitadas de BSD (o contrário é raro devido às licenças).
Isto também não quer dizer, contudo, que haja uma integração sistemática ente Linux e *BSD.
O Ancestor ali em cima disse que isso pode ser mais contra-produtivo num projecto com objectivos especificos. E parece-me que é exactamente a opinião vigente nos *BSD.
E, na minha opinião, a têndencia é de a base de código do NetBSD e do OpenBSD se afastarem progressivamente, tal como o NetBSD e o FreeBSD se afastarem (antepassado comum: 386BSD).
E integração não é apenas o backport pontual de uma bloco de código de um para outro. Também há que considerar a evolução continua desse código: detecção e correcção de erros, melhorias. Nitpick: O NetBSD usa o OpenSSH portável.. Finalmente, eu diria que o Apache, o Gnome, o KDE, etc, têm uma base comum. E é comum as distribuições Linux alterarem-nos relativamente a esse base.
Mesmo que excluas o software que é genérico para Unix e consideres apenas as ferramentas próprias das distribuições (e sim, eu estava a considerar os forks de distribuições) e código que é especifico de Linux/FreeBSD/NetBSD/OpenBSD continuas a ter uma boa colecção de código onde testar a minha teoria.
|
| | | | | E, na minha opinião, a têndencia é de a base de código do NetBSD e do OpenBSD se afastarem progressivamente, tal como o NetBSD e o FreeBSD se afastarem (antepassado comum: 386BSD). Respeitando o teu direito a opinião, não concordo com a tua afirmação. O NetBSD e o OpenBSD, apesar de possuirem uma raiz comum, ainda não apresentaram até hoje nada que sugerisse esse afastamento gradual, bem pelo contrário. Pelo que sei, muito do trabalho de SMP realizado no OpenBSD foi baseado em trabalho similar no NetBSD. Também há que considerar a evolução continua desse código: detecção e correcção de erros, melhorias. Mas a evolução do código e as normalmente ocorrem sempre na tree de destino, não na de origem, precisamente porque essa evolução é ditada pelas características e pelos objectivos do sistema. Por exemplo, o OpenBSD integrou uma versão do apache na sourcetree precisamente porque a equipa do apache não ligava puto aos patches enviados pela equipa. E o resultado é que o apache disponibilizado pelo OpenBSD possui inúmeras melhorias, refinamentos, e até menos susceptibilidades de segurança que o distinguem do original. Outra situação em que o feedback foi tentado foi no caso do ipf; O autor do ipf não fazia a manutenção do código, daí a equipa ter procurado uma alternativa que pudessem manter. Nitpick: O NetBSD usa o OpenSSH portável.. Eu estou ciente disso. O FreeBSD também. No entanto, o OpenSSH é integrado no código do userland, sendo parte integrante do sistema como um todo (e, claro, integrado na sourcetree). Por vezes são também adicionados patches ao openssh integrado na sourcetree para uma melhor interacção com o resto dos componentes. Experimenta desactivar a compilação do openssh aquando um build de source no FreeBSD ou no NetBSD, e verás que existem diversos serviços e utilitários que dependem dele. Mais, o "equivalente" ao ssh disponível na generalidade das distros linux está disponível também na portstree de ambos os SO's. Permite-te instalar a última versão do openssh portable caso desejes (visto que muitas vezes a versão in-tree não é a mais recente).
|
| | | | | Creio que te escapa o aspecto fundamental da coisa: esforço. Tomemos como exemplo o caso do Apache vs OpenBSD.
Uma vez que as melhorias pretendidas pelo OpenBSD não foram integradas no Apache base, todos aqueles que contribuem para o Apache base vão fazê-lo ignorado as alterações do OpenBSD. Isso significa que, por vezes, vão aparecer coisas no Apache base que vão obrigar o OpenBSD ao esforço de reescrever essas melhorias para as poder ter num Apache recente. E os developers do OpenBSD de certeza que poderiam fazer coisas melhores com o seu tempo. No caso do NetBSD vs OpenBSD tens uma situação ainda mais extrema: um fork total. O OpenBSD não importa sistematicamente as alterações feitas no NetBSD. E se há comunicação e até partilha de pessoas entre os dois, também há diferenças (por alguma razão aconteceu o fork). É perfeitamente natural que, com o tempo e evolução, se torne cada vez mais trabalhoso integrar código do NetBSD no OpenBSD e vice-versa. Se fosse possivel evitar isso, não teria havido o fork. Uma última nota sobre o OpenSSH: só referi o facto de o NetBSD usar o OpenSSH portável porque isso significa que não é um trabalho de integração pôr o OpenSSH a funcionar em NetBSD, ao contrário, por exemplo, do pf e as outras coisas que referiste.
|
| | | | | Uma vez que as melhorias pretendidas pelo OpenBSD não foram integradas no Apache base, todos aqueles que contribuem para o Apache base vão fazê-lo ignorado as alterações do OpenBSD. Não foram integradas no Apache original porque os responsáveis pelo Apache não o quiseram. As modificações/adições foram frequentemente enviadas à equipa do Apache. Ou seja, de todas as vezes que havia uma nova versão do Apache, havia todo o trabalho de reimplementar as modificações no openbsd. Mas talvez o factor que mais tenha pesado no fork tenha sido a mudança da licença do Apache. O que é certo é que o Apache do openBSD é bem mais robusto que o original. (...)por alguma razão aconteceu o fork O fork ocorreu por opiniões divergentes na orientação do sistema operativo, aliás à semelhança do que aconteceu no caso FreeBSD/DragonFly, e que só comprova o que afirmei inicialmente - em projectos com objectivos específicos normalmente a retroportabilidade é contraproducente, precisamente dada a divergência de objectivos. O que, claro, não impede a integração comum de features.
|
| | | | Claro, claro.
Eu usei apenas o exemplo do Apache para ilustrar os problemas de manter um fork vs integrar tudo na base comum. Não pretendia dizer que não se deva fazer quando não se consegue a integração.
|
| | | | O modelo de desenvolvimento no Linux é em árvore. Na base podem haver muitas distribuições, mas bebem todas da mesma água.
A diferença é que no Linux (e projectos associados), o forking é sempre temporário e a tendência é sempre fazer o merge das diferenças com a referência. Nos BSD os tipos chateiam-se e voilá, temos um novo sistema operativo.
--
Carlos Rodrigues
|
| | | | "os tipos chateiam-se e voilá, temos um novo sistema operativo."
AHAHAHAHAHAHAHAH. Adoro o teu sentido de humor.
|
| | | | | | Nos BSD os tipos chateiam-se e voilá, temos um novo sistema operativo. O giro é que esse "novo sistema operativo" costuma correr não só aplicações de vários BSD, como também as de linux, sem grande espiga - que é mais do que o que se pode dizer de algumas distros linux...
No fundo a grande diferença entre uma distro linux e um fork de BSD é que no caso do BSD é "uma abordagem com objectivos específicos" e no caso do linux é "mais do mesmo".
|
| | | | Normalmente no linux os grandes hits são "a minha distro é melhor que a tua" e "o linux é melhor que o windows". Curiosamente, na comunidade BSD é perfeitamente normal encontrar utilizadores de vários BSD, é perfeitamente normal coexistirem pacificamente no mesmo recinto (como encontros, conferências, etc), trocarem experiências, e em muitos casos até já passaram a idade das borbulhas. Os gajus dos BSD's até se podem chatear, mas não há nada que chegue a uma verdadeira linux zealot fight com pipocas.
|
| | | | Também é normal coexistirem utilizadores de diferentes distribuições de Linux, tal como é comum encontrar utilizadores de mais do que uma (eu uso Fedora e SuSE regularmente). Da mesma forma que também se encontra muita gente que usa Linux e algum BSD.
É verdade que existem distribuições de Linux a mais, eu já estou farto de o dizer. E a maioria delas são irrelevantes.
Mas é bom não esquecer que os BSDs já cá andam há muitos anos, mais do que o Linux. No entanto, o Linux tem hoje uma projecção ordens de magnitude acima de qualquer BSD e já não se pode dizer que é tudo "hype" porque não começou ontem.
Há Linux a correr desde os mais pequenos servidores aos maiores supercomputadores ou mainframes, o mesmo já não se pode dizer dos BSDs que ainda andam às voltas a tentar arranjar um suporte SMP "decente" (não digo que não seja bom, mas é mais limitado do que o do Linux).
Supondo que quem desenvolve para os BSDs não tem menor qualidade do que quem desenvolve para o Linux, a única explicação para esta diferença está no modelo de desenvolvimento e na atitude da comunidade.
Esclarecido?
--
Carlos Rodrigues
|
| | | | | Também é normal coexistirem utilizadores de diferentes distribuições de Linux, tal como é comum encontrar utilizadores de mais do que uma (eu uso Fedora e SuSE regularmente). Então as discussões de "a minha distro é melhor que a tua" e "windoze suxx" só ocorrem na internet? Da mesma forma que também se encontra muita gente que usa Linux e algum BSD. Sem querer soar arrogante (e soando na mesma), o normal é encontrares gente que use BSD e algum linux. Há Linux a correr desde os mais pequenos servidores aos maiores supercomputadores ou mainframes, o mesmo já não se pode dizer dos BSDs que ainda andam às voltas a tentar arranjar um suporte SMP "decente" (não digo que não seja bom, mas é mais limitado do que o do Linux). Pois, mas existem dois factores que contribuem para isso. O primeiro é a licença GPL, que implica que modificações que qualquer empresa faça no source kernel com objectivo de distribuição tenham que ser também estas publicitadas. O outro é a falta de objectivos; Enquanto em linux não existe um plano concreto de desenvolvimento, isso não acontece em BSD. A relevância da estabilidade em BSD não é nada que se compare com o que se procura no linux. Se bem que o suporte SMP nos BSD's não é nada de extraordinário, isso não parece incomodar as milhares de empresas que confiam em BSD há anos (e não políticas de upgrade anti-Microsoft que surgem em alturas de aperto financeiro). Por outro lado, o VMM do linux não é nada de extraordinário. Não me ocorre nada em que o linux seja realmente "forte" no sentido de "a melhor escolha possível". A título pessoal, uma coisa que me faz muita impressão no linux é a "responsiveness" geral do sistema em carga (ou falta de). Mas eu também sou suspeito para afirmar isso :) Supondo que quem desenvolve para os BSDs não tem menor qualidade do que quem desenvolve para o Linux, a única explicação para esta diferença está no modelo de desenvolvimento e na atitude da comunidade. Já expliquei que a licença GPL na sua natureza mais restritiva também ajuda. Em termos de qualidade de código, e não desfazendo no pessoal muito competente que também desenvolve para linux, o BSD bate aos pontos o linux. Também o facto de os projectos BSD terem objectivos bem definidos e uma abordagem mais ou menos coerente ajuda a que o esforço de programação seja concentrado num sentido em vez de disperso em features menos importantes. Já agora, não é de todo incomum encontrar pessoas que deixaram de usar linux para usar BSD, mas o contrário é muito raro. Porque será?
|
| | | | | Também há empresas que confiam no Linux há anos. A SUSE e RedHat não vivem do ar. E também temos os casos da IBM e SGI. Mas até há quem confie no Windows, imagine-se. Nada disso é relevante para o que o CrLf referiu.
Ele não estava a falar do interesse do suporte para SMP (que, com os CPUs a implemntar *MT/CMP é cada vez mais importante) mas a exemplificar um aspecto onde a evolução do Linux ultrapassou os *BSD, como consequência dos modelos de desenvolvimento. Que tem sido mais ou menos a história do Linux: começar atrás dos BSD e ultrapassá-los. E a explicação para isso é o modelo de desenvolvimento. O outro é a falta de objectivos; De facto, este é o cerne da questão: o modelo de desenvolvimento do Linux não tem objectivos especificos, mas também não faz cedências para os atingir. Também o facto de os projectos BSD terem objectivos bem definidos e uma abordagem mais ou menos coerente ajuda a que o esforço de programação seja concentrado num sentido em vez de disperso em features menos importantes. Outra diferença crucial. Os *BSD continuam a funcionar com uma mentalidade tipica de software in-house. Meia dúzia de pessoas definem uma linha orientadora e tentam levar os outros a segui-la. Isto tende a resultar mal no mundo do software produzido por voluntários.
Todas essas features "menos importantes" foram suficientemente importantes para alguém se dar ao trabalho de as escrever. Desde que não seja demasiado disruptivo, nada é rejeitado desde que alguém se chegue à frente para o fazer. Para responder à tua pergunta final: sendo o Linux mais popular, é natural que o primeiro contacto das pessoas com um Unix seja com ele. Se vão mudar, será de Linux para *BSD.
|
| | | | | Também há empresas que confiam no Linux há anos. A SUSE e RedHat não vivem do ar. E também temos os casos da IBM e SGI. Mas até há quem confie no Windows, imagine-se. Nada disso é relevante para o que o CrLf referiu. Sem querer entrar em detalhes relativos aos ins e outs de cada uma das empresas, não esquecer que a idade da inocência já passou. Trata-se de lucro. Se a "moda" é o linux, convém assegurar o nicho de mercado. (..)mas também não faz cedências para os atingir. Ocorre-me o caso do USB no 2.4,por exemplo, em que a falta de estratégia não facilitava em nada o desenvolvimento de drivers. Outra diferença crucial. Os *BSD continuam a funcionar com uma mentalidade tipica de software in-house. Meia dúzia de pessoas definem uma linha orientadora e tentam levar os outros a segui-la. Isto tende a resultar mal no mundo do software produzido por voluntários. Isso é verdadeiro e falso. Se por um lado existe uma "core team" que define a linha orientadora, por outro o trabalho também é feito por voluntários. No caso do FreeBSD, por exemplo, os commiters são eleitos regularmente. Talvez porque a abordagem dos developers BSD é regra geral, menos caótica, dá a impressão de ser mais fechada, mas isso não corresponde à verdade. Todas essas features "menos importantes" foram suficientemente importantes para alguém se dar ao trabalho de as escrever. Voltamos à questão dos objectivos. A abordagem linux é mais genérica que a abordagem BSD. Não obstante, nada impede ninguém de desenvolver uma determinada funcionalidade para BSD e provavelmente vê-la integrada no source, independentemente da sua importância.
|
| | | | | Todas as empresas vivem para o lucro. Tu foste o primeiro a referir empresas que usam *BSD há anos. Eu apenas exemplifiquei que também há por ai empresas (SUSE, RedHat) que há anos que VIVEM do Linux. E vivem porque outras empresas usam Linux.
"idade da inocência"? Não fazes sentido.
"moda"? É verdade que o Linux está na moda. E há empresas que estão apenas na onda. Até podes dizê-lo de empresas como a IBM e a Novel. Nenhuma delas apostou a sua continuidade no Linux. Mas a RH nasceu para isso antes de o Linux ser moda e a SGI fê-lo num mercado onde os clientes tanto usam X como Y. Ocorre-me o caso do USB no 2.4,por exemplo, em que a falta de estratégia não facilitava em nada o desenvolvimento de drivers. Defeitos no Linux não faltam. Mas o sistema evolui. Os *BSD evoluem. A diferença esta na velocidade a que estão a evoluir. E na direcção.
|
| | | | Então as discussões de "a minha distro é melhor que a tua" e "windoze suxx" só ocorrem na internet?
A comunidade de utilizadores de Linux é muito vasta, e inclui o desktop. É pela ausência destes dois factores nos BSD que não se encontram lá este tipo de discussões. Quem utiliza o Linux para assuntos sérios (nomeadamente servidores) normalmente não entra neste tipo de discussões. Ou pelo menos entra pela positiva, tal como estou certo que acontece nos BSD (seria aberrante se não defendessem a sua "dama").
Pois, mas existem dois factores que contribuem para isso. O primeiro é a licença GPL, que implica que modificações que qualquer empresa faça no source kernel com objectivo de distribuição tenham que ser também estas publicitadas.
Esta é muito boa... afinal de contas a licença GPL agora favorece as contribuições. Então isto significa que a velha história do código BSD livre e disponível para fins proprietários afinal está furada e só contribui para que os espertos se aproveitem do trabalho dos tansos sem que estes ganhem alguma coisa (nem sequer melhoramentos do seu próprio código). Se calhar os BSD deviam mudar para GPL...
O outro é a falta de objectivos; Enquanto em linux não existe um plano concreto de desenvolvimento, isso não acontece em BSD. A relevância da estabilidade em BSD não é nada que se compare com o que se procura no linux.
Hmmm, e eu que pensava que a falta de objectivos era penalizadora, afinal parece que não.
Quanto à estabilidade, o Linux está hoje a ser usado em alguns casos interessantes na área financeira, deve ser por ser instável e de pouca confiança...
(...)políticas de upgrade anti-Microsoft que surgem em alturas de aperto financeiro(...)
Sugiro que te informes, porque a expansão do Linux no server space tem sido principalmente à custa dos Unixes proprietários e não do Windows. A competição com o Windows está a acontecer principalmente em sistemas novos, e realmente não acredito que o custo seja o mais importante quando se gastam alguns trocados em hardware, especialmente se considerarmos os custos de suporte da Red Hat ou SuSE.
Resumindo, eu não estou a criticar a qualidade técnica dos BSD, mas a estrutura organizacional (como já disse). O que me parece é que cada vez que são criticados, o pessoal do BSD vem logo com a conversinha de irmão mais velho, como se o Linux fosse uma criancinha engraçadinha mas pouco mais. Acho deviam abrir os olhos e ver a realidade.
--
Carlos Rodrigues
|
| | | | | É pela ausência destes dois factores nos BSD que não se encontram lá este tipo de discussões. Quem utiliza o Linux para assuntos sérios (nomeadamente servidores) normalmente não entra neste tipo de discussões. Ou pelo menos entra pela positiva, tal como estou certo que acontece nos BSD (seria aberrante se não defendessem a sua "dama"). Se bem entendi, segundo a tua perspectiva não existe desktop em BSD. E os administradores que usam linux são automaticamente excluídos do grupo de linux zealots e trolls. Interessante. Esta é muito boa... afinal de contas a licença GPL agora favorece as contribuições. Então isto significa que a velha história do código BSD livre e disponível para fins proprietários afinal está furada e só contribui para que os espertos se aproveitem do trabalho dos tansos sem que estes ganhem alguma coisa (nem sequer melhoramentos do seu próprio código). O que existe é uma limitação da liberdade de utilização inerente ao uso da GPL. O código BSD é livre, não tem "se's". Por outro lado, se a IBM modifica o código do kernel e distribui aos clientes, é obrigada a publicar as modificações, ou não? Quanto à questão dos "tansos" só trabalha no projecto quem quer, ninguém é obrigado. Mas até já têm surgido situações em que empresas patrocinam developers do FreeBSD para implementar características específicas. Sugiro que te informes, porque a expansão do Linux no server space tem sido principalmente à custa dos Unixes proprietários e não do Windows. Quem é que falou em servers? Ah pois, esquece, não existem desktops BSD... Até porque todos nós vemos todas as grandes empresas que usam Tru64, HP-UX e Solaris a correrem para implementar linux nos seus servers... Isto para não falar no VMS, que apesar de não ser Unix, tem tido um crescimento considerável nos últimos tempos. È certo que existem situações em que o linux se apresenta como uma alternativa viável e de suporte mais barato, mas ainda estou para ver a migração de Unix para Linux em que o critério de mudança é exclusivamente a fiabilidade. (...) e realmente não acredito que o custo seja o mais importante quando se gastam alguns trocados em hardware, especialmente se considerarmos os custos de suporte da Red Hat ou SuSE (...) As grandes migrações para linux continuam a ser pontuais, e em muitos casos vindas de Windows (mais do que de Unixes proprietários). O mais curioso é que há casos de empresas que abandonaram o linux e voltaram ao Windows, por diversos motivos. Por outro lado, o facto de ter tido crescimento não significa que é bom, significa que é popular, e isso realmente é inegável. o pessoal do BSD vem logo com a conversinha de irmão mais velho Eu paternalizei alguém? Se sim, não era minha intenção. Irmão mais velho ou não, o que é certo é que a estabilidade obtida num BSD normalíssimo é superior ao obtida com uma distro de linux (sujeito, claro, à instabilidade inerente dos serviços que corre). Por superior eu quero dizer a capacidade de aguentar/recuperar de situações de carga elevada e exaustão de recursos sem comprometer a execução e disponibilidade dos processos e recursos já alocados. como se o Linux fosse uma criancinha engraçadinha mas pouco mais. Eu acho que é uma criança bem feia, mas pode ser da idade do "rebento" :) Acho deviam abrir os olhos e ver a realidade. Qual delas?
|
| | | | Se bem entendi, segundo a tua perspectiva não existe desktop em BSD. E os administradores que usam linux são automaticamente excluídos do grupo de linux zealots e trolls. Interessante.
Por um lado, na prática não existe desktop em BSD, quer tu queiras quer não. Por outro lado, em todos os grupos há zelotas e trolls, mesmo nos BSD. Mas é claro que a maioria deles estão nas massas não-profissionais, e essas só existem em Linux (pelo menos em quantidades não-desprezáveis).
O que existe é uma limitação da liberdade de utilização inerente ao uso da GPL. O código BSD é livre, não tem "se's". Por outro lado, se a IBM modifica o código do kernel e distribui aos clientes, é obrigada a publicar as modificações, ou não? Quanto à questão dos "tansos" só trabalha no projecto quem quer, ninguém é obrigado. Mas até já têm surgido situações em que empresas patrocinam developers do FreeBSD para implementar características específicas.
A verdade é que as limitações de "liberdade" (a liberdade de se apropriar do trabalho dos outros não é uma liberdade) impostas pela GPL parecem não desmotivar ninguém, muito pelo contrário, pois impedem uma empresa concorrente de se apropriar do trabalho de outra, ao mesmo tempo que se aproveitam os benefícios das contribuições da comunidade.
Até porque todos nós vemos todas as grandes empresas que usam Tru64, HP-UX e Solaris a correrem para implementar linux nos seus servers...
Debaixo de que pedra é que tu vives?! O Linux não está a roer o mercado Unix?! Por favor... ao menos evita usar argumentos ridículos.
É claro que ainda existe muito Unix proprietário por aí, pois se funciona bem não se mexe, mas olha bem para o seu crescimento... é nenhum, quando não é negativo (instalações renovadas que acabam por passar para Linux como bónus).
Olha bem para o mundo, e vais ver uma IBM a apostar cada vez menos no AIX (até porque o Linux corre em quase toda a sua gama de hardware, até em máquinas de grande porte para as quais nunca existiu AIX), uma SGI a mandar o IRIX pastar (até os novos sistemas de visualização deles são Linux), uma HP a cravar o último prego no Tru64 e com menos ênfase no HP-UX do que antigamente, e uma Sun a ver o seu Solaris a perder terreno contra o Linux em x86 a passos largos. Tudo isto porque o interesse do mercado nos Unixes proprietários está a desaparecer, para ser substituido pelo Windows ou Linux.
Isto para não falar no VMS, que apesar de não ser Unix, tem tido um crescimento considerável nos últimos tempos.
Hã!? Crescimento no VMS... só podes estar a brincar. De certeza que não é por ajuda da HP que anda a adiar o VMS em Itanium (como migração do VMS em Alpha) há montes de tempo...
mas ainda estou para ver a migração de Unix para Linux em que o critério de mudança é exclusivamente a fiabilidade.
O Linux é hoje tão fiável como qualquer outro Unix, pois é claro que a fiabiliade não é o critério de migração...
As grandes migrações para linux continuam a ser pontuais, e em muitos casos vindas de Windows (mais do que de Unixes proprietários).
Como eu já disse, vai-te informar antes de dizer baboseiras (antes fosse verdade, mas não é).
As grandes migrações para linux continuam a ser pontuais, e em muitos casos vindas de Windows (mais do que de Unixes proprietários).
Andas a ler muita propaganda vinda da Microsoft... A verdade é que esses casos são raros e acontecem no desktop, onde poucas empresas migraram para Linux de uma forma consistente.
o que é certo é que a estabilidade obtida num BSD normalíssimo é superior ao obtida com uma distro de linux (sujeito, claro, à instabilidade inerente dos serviços que corre). Por superior eu quero dizer a capacidade de aguentar/recuperar de situações de carga elevada e exaustão de recursos sem comprometer a execução e disponibilidade dos processos e recursos já alocados.
Devo assumir que não estás a tirar estas conclusões do rabo, ou devo? Teres Linux a aguentar backends de correctoras da bolsa, parte de sistemas transaccionais de bancos, etc. não te acende nenhuma luzinha?
Eu acho que é uma criança bem feia, mas pode ser da idade do "rebento" :)
Pois, acho que isto resume o que disseste até agora. Quem é que é o zelota e troll aqui?
--
Carlos Rodrigues
|
| | | | A verdade é que as limitações de "liberdade" (a liberdade de se apropriar do trabalho dos outros não é uma liberdade) impostas pela GPL parecem não desmotivar ninguém, muito pelo contrário, pois impedem uma empresa concorrente de se apropriar do trabalho de outra, ao mesmo tempo que se aproveitam os benefícios das contribuições da comunidade.
Tenho a certeza absoluta que não estás por dentro da licença BSD. Desde quando é que com uma licensa BSD tu podes apropriar código de alguém ? A GPL sempre te limitou muito mais do que a licença BSD...
|
| | | | Não podes pegar em código BSD e enfiar em software proprietário sem dar cavaco ao autor? No meu dicionário isso chama-se apropriação. Não o podes fazer com a GPL.
--
Carlos Rodrigues
|
| | | | Sem dar cavaco ao autor ? Informa-te melhor. Porque é que será que quando tu instalas FreeBSD aparecem vários Copyrights ?
|
| | | | A licença BSD actual não obriga a colocar créditos. É simpático colocar créditos visiveis, mas não é obrigatório.
--
Carlos Rodrigues
|
| | | | Depende das clausulas que lá estiverem...
|
| | | | É a diferença entre a licença bsd com 3 cláusulas (que é incompativel com GPL) e a versão de 2 cláusulas.
|
| | | | Tens exemplos de uso de Linux em backends de sistemas financeiros como uma bolsa ou banco?
Sempre tive a ideia de que são playground quase exclusivo de VMS, z/OS, NSK. GCOS talvez também. Não só por questões de RAS mas também por questões de compatibilidade. Li há tempos num sitio qualquer que um quarto da informação financeira do mundo está armazenada em mainframes só acessiveis por SNA. :)
|
| | | | Podes começar por estes exemplos (uns mais para o backend, outros mais para o frontend):
No caso dos bancos, é pouco provavel veres Linux no backend, se considerares como "backend" apenas o "core". Aí nem sequer muito Unix há. A maioria destes sistemas são demasiado antigos e ninguém lhes quer tocar (porque é que acham que um zSeries deste ano ainda consegue correr software de 1960?).
--
Carlos Rodrigues
|
| | | | | Por um lado, na prática não existe desktop em BSD, quer tu queiras quer não. O que distingue um BSD de um desktop? E o que distingue um BSD em desktop de um linux em desktop? A verdade é que as limitações de "liberdade" (a liberdade de se apropriar do trabalho dos outros não é uma liberdade) impostas pela GPL parecem não desmotivar ninguém, muito pelo contrário, pois impedem uma empresa concorrente de se apropriar do trabalho de outra, ao mesmo tempo que se aproveitam os benefícios das contribuições da comunidade. Vês alguém desmotivado com a licença BSD? Quando à apropriação, a GPL não te impede puto. Apenas te impede de teres a liberdade de fazeres o que bem entenderes com as modificações ou trabalhos derivados. Quanto ao linux em mercado unix, sugiro que faças uma análise mais completa. Se olhares mais atentamente, verás que o $1B de receita linux no terceiro trimestre deste ano se devem essencialmente a vendas de servidores x86 de baixo custo. Ora, com o crescimento esperado do mercado de blades a IBM só se fosse estúpida é que não investia em linux. No mesmo período de tempo o mercado de midrange servers teve uma descida de 10%, e o mercado de mainframes apresentou um aumento de 1.9%. Outro facto curioso é que o Windows (que compete no mesmo mercado que o linux) também apresentou um crescimento de 13%. Ora, a única coisa que se pode concluir é que hove um aumento de procura de servidores x86 de entrada de gama, quer com linux, quer com windows, e que os mercados típicos dos unixes proprietários (midrange servers, mainframes) apresentaram globalmente quebras. Explica-me lá onde vês que a adopção do linux tem como base a fiabilidade e o desempenho do mesmo em servidores de grande porte. E gostava também de saber porque é que a maioria das grandes instituições financeiras no mundo inteiro não usam linux nos seus servers principais. E correndo o risco de dizer mais uma baboseira, explica lá então a importância do SMP numa altura em que o mercado tende para soluções horizontais em vez de soluções verticais, e como a estabilidade pode ser um factor secundário em diversas aplicações. Hã!? Crescimento no VMS... só podes estar a brincar. De certeza que não é por ajuda da HP que anda a adiar o VMS em Itanium (como migração do VMS em Alpha) há montes de tempo... Não, não estou a brincar, até porque o mercado dos mainframes não vive de hype. Em caso de dúvidas, dá uma olhada por aqui, aqui e aqui . Claro que ninguém te impede de achares o que quiseres. Devo assumir que não estás a tirar estas conclusões do rabo, ou devo? Teres Linux a aguentar backends de correctoras da bolsa, parte de sistemas transaccionais de bancos, etc. não te acende nenhuma luzinha? Humm e não tens Windows a fazer isso, também? E HP-UX? e VMS? E BSD? Olha curiosamente os servers da Compaq/HP até têm uma feature porreira que te reinicia o server quando crasha. Curiosamente, eles estão em 2º lugar em $$$ no mercado de servers linux. Quem é que é o zelota e troll aqui? Quando uma frase começa por "Acho" ou "Eu acho", implica que o resto da frase transmite uma opinião pessoal. Se tu achas que dizer algo como opinião pessoal é ser zealota e troll, então talvez não fosse mal leres o que escreves.
|
| | | | E o que distingue um BSD em desktop de um linux em desktop?
O facto de haver um número não desprezável de utilizadores a usá-lo nesses moldes.
Vês alguém desmotivado com a licença BSD?
Aparentemente sim, dada a diferença de dimensão entre a comunidade mais-GPL (Linux) e mais-BSD.
Quando à apropriação, a GPL não te impede puto. Apenas te impede de teres a liberdade de fazeres o que bem entenderes com as modificações ou trabalhos derivados.
Estou a ver que há muita gente aqui que não percebe português... Impedir de fazer o que se quer é bom quando isso significa impedir que alguém pegue no meu código e o torne proprietário sem me dar cavaco nem devolver nada à comunidade.
Quanto ao linux em mercado unix, sugiro que faças uma análise mais completa. Se olhares mais atentamente, verás que o $1B de receita linux no terceiro trimestre deste ano se devem essencialmente a vendas de servidores x86 de baixo custo. Ora, com o crescimento esperado do mercado de blades a IBM só se fosse estúpida é que não investia em linux. No mesmo período de tempo o mercado de midrange servers teve uma descida de 10%, e o mercado de mainframes apresentou um aumento de 1.9%. Outro facto curioso é que o Windows (que compete no mesmo mercado que o linux) também apresentou um crescimento de 13%. Ora, a única coisa que se pode concluir é que hove um aumento de procura de servidores x86 de entrada de gama, quer com linux, quer com windows, e que os mercados típicos dos unixes proprietários (midrange servers, mainframes) apresentaram globalmente quebras.
Boa, se não consegues descobrir aí a contradição em que estás a cair, eu dou-te uma dica: o x86 está a trucidar tudo e todos. Os servidores mid-range são cada vez mais máquinas x86.
E correndo o risco de dizer mais uma baboseira, explica lá então a importância do SMP numa altura em que o mercado tende para soluções horizontais em vez de soluções verticais, e como a estabilidade pode ser um factor secundário em diversas aplicações.
É normal a tentativa de minimizar os pontos fortes dos adversários.
A estabilidade é um factor importante sempre, o que se pode é tolerar mais ou menos a instabilidade (e a tolerância depende do grau de exposição prévia a sistemas Windows).
Quanto à escalabilidade, as soluções horizontais não são pau para toda a obra. Em muitos casos é preferível ir para máquinas de maior porte, com paralelismo interno (SMP) do que ganhar dores de cabeça aumentando o número de máquinas.
Humm e não tens Windows a fazer isso, também? E HP-UX? e VMS? E BSD?
Pois tens, mas tu é que pões em causa a qualidade do Linux nessa área. Quanto a haver BSDs aí, devem haver alguns, mas eu nunca ouvi falar, sugiro que vás à procura e me proves o contrário.
Olha curiosamente os servers da Compaq/HP até têm uma feature porreira que te reinicia o server quando crasha. Curiosamente, eles estão em 2º lugar em $$$ no mercado de servers linux.
Sabes o que se chama a isto? "Non sequitur", que quer dizer "nada a ver, não faço a menor ideia do que isto tem a ver para o caso". Se estás a tentar associar o facto de terem um hardware watchdog com a alegada instabilidade do Linux, vou ter de dizer que deves ser parvo e devias ir pentear macacos.
Tu continuas a tentar tapar o Sol com a peneira, a fingir que o Linux não existe e não tem as qualidades que já foram mais que comprovadas. Se tens vergonha ou inveja dos BSDs não estarem a partilhar da mesma popularidade, azar. Eu já disse porque acho que isto acontece.
--
Carlos Rodrigues
|
| | | | | Muito rapidamente... O facto de haver um número não desprezável de utilizadores a usá-lo nesses moldes. Explica-me que moldes definem um desktop... E o que é que não encontras normalmente num BSD que o impede de o ser, ou que te sugere que o utilizador não o vai usar para esse fim. Estou a ver que há muita gente aqui que não percebe português... Impedir de fazer o que se quer é bom quando isso significa impedir que alguém pegue no meu código e o torne proprietário sem me dar cavaco nem devolver nada à comunidade. Ainda bem que muita gente não pensa como tu. Se o queres dar à comunidade dá, mas não te ponhas com falsos moralismos. Já agora, isso de o tornar proprietário sem dar cavaco também acontece com a GPL, apesar de a licença não o permitir. Dá uma olhada no hall of shame do busybox. É normal a tentativa de minimizar os pontos fortes dos adversários. Se em vez de teres uma máquina com grande poder de processamento tens múltiplas mais pequenas, o SMP em grande volume deixa de ser essencial. E o que se tem verificado é um decréscimo nos midrage servers em preferência a soluções de alto volume. (..)e a tolerância depende do grau de exposição prévia a sistemas Windows Curiosamente, tens Windows com a mesma aplicação que indicaste como apontador da qualidade do linux... Pois tens, mas tu é que pões em causa a qualidade do Linux nessa área. Ainda não me apresentaste um caso em que o factor de migração fosse a qualidade do Linux. Eu não puz em causa a popularidade do mesmo. Apenas me limitei a relembrar que, em época de abrandamento económico, o factor preço é muito importante, e os casos de migraçao se devem mais a políticas de contenção de custos do que à qualidade do linux. Sabes o que se chama a isto? "Non sequitur", que quer dizer "nada a ver, não faço a menor ideia do que isto tem a ver para o caso". Se estás a tentar associar o facto de terem um hardware watchdog com a alegada instabilidade do Linux, vou ter de dizer que deves ser parvo e devias ir pentear macacos. Já deixaste ciente que educação não é o teu forte; Não obstante, um dos problemas dos servers x86 de baixo custo são os encravanços. Se tiveres um datacenter com 4 racks de blades, é normal que tenhas diversas máquinas a encravar pontualmente. Por outro lado, os sistemas equivalentes verticais, dada a sua natureza, têm que oferecer uma fiabilidade superior ao obtida nas blades, visto que um encravanço pode mandar abaixo milhares de serviços. Tu continuas a tentar tapar o Sol com a peneira, a fingir que o Linux não existe e não tem as qualidades que já foram mais que comprovadas. Se tens vergonha ou inveja dos BSDs não estarem a partilhar da mesma popularidade, azar. Eu já disse porque acho que isto acontece. Como sempre, eloquente. Eu acho que cada um usa o que quiser, se estás satisfeito com o linux, óptimo. Quanto à popularidade dos BSD's, talvez andes mal informado - todos eles têm apresentado um crescimento brutal em popularidade. Não que isso me interesse muito, eu não sou dado a modas. Talvez daqui a dois ou três anos a penetração do linux no mercado seja realmente grande, mas ainda é demasiado cedo para afirmar isso. O melhor é esperar para ver.
|
| | | | Explica-me que moldes definem um desktop... E o que é que não encontras normalmente num BSD que o impede de o ser, ou que te sugere que o utilizador não o vai usar para esse fim.
Caramba! Eu não falei na parte técnica, apenas que não há um número relevante de pessoas a usar BSD no desktop.
Já deixaste ciente que educação não é o teu forte
Talvez, ou então a minha paciência para tipos densos e com argumentos furados é baixa...
Portanto, eu já disse tudo o que pensava com detalhe suficiente, se não percebeste então volta atrás e lê de novo.
--
Carlos Rodrigues
|
| | | | | Caramba! Eu não falei na parte técnica, apenas que não há um número relevante de pessoas a usar BSD no desktop. Continuas sem explicar o que queres dizer com "desktop". Talvez se perdesses menos tempo a dizer o que pensas e mais a ler, percebesses o que escrevi, em vez de baixares o nível. A troca de ideias e argumentos é sempre saudável, não há motivo para perderes a compostura, nem te dei razões para seres bronco. Houve outras pessoas que discordaram da minha opinião, e não foram mal educadas ou boçais. Não é meu objectivo evangelizar ninguém nem obrigar ninguém a utilizar o que eu uso - se não consegues perceber isso, então, meu caro, lamento. Mais não posso fazer.
|
| | | | | Tens uma conclusão errada: como referiste umas linhas antes, o mercado de mainframes cresceu.
Adiante, o facto do crescimento do Linux ser principalmente em servidores de pequeno porte não exclui o crescimento em servidores maiores. A verdade é que há poucos números sobre que SOs são enviados com as máquinas. Mais ainda, essas máquinas têm a capacidade de correr vários SOs em paralelo e tempos de vida relativamente longos pelo que esses números podem não ser muito representativos da realidade de que SOs correm nelas.
Uma fonte melhor seriam os números dos contractos de suporte, mas parece que era mais fácil saber o nº de telefone da Claudia Shiffer.
Mas temos uma fonte qualitativa: a quantidade de software e suporte disponivel.
Tomando como exemplo a óbvia IBM, poder ver que a gama de soluções Linux deles não se resume a sistemas x86 pequenos.
Do lado do hardware tens xSeries até 32 CPUs em que as alternativas são Windows ou Linux e até modelos de iSeries e zSeries só com suporte para Linux.
Também tens software q.b: compiladores, DB2, Java, Websphere. Não em todas as combinações possiveis mas uma dose interessante.
Não sabemos quanto é que isto vende realmente, mas podemos inferir que há algum interesse senão a IBM não se dava ao trabalho. Já agora, sobre o VMS: se reparares, nenhum daqueles três artigos aponta números de crescimento do VMS. Embora também nao tenha números, creio CrLf tem razão nisso: o crescimento do VMS está a ser afectado pelas transição de Alpha para Itanium e está um bocado em compasso de espera de momento. Quando o VMS para Itanium estiver disponivel, as coisas são capazes de mudar.
|
| | | | | Apesar do mercado de mainframes ter crescido pouco mais de 1% o segmento de midrange servers teve uma quebra de 10%, talvez explicada pelo aumento de procura de soluções horizontais de alto volume (blades) em vez de soluções verticais (servidores de médio porte). Ora, o que é efectivo, é que o mercado está em mudança, e que isso sim, afecta o segmento dos unixes comerciais. Se existe um aumento nas vendas x86 e as opções dos grandes fabricantes são Windows e Linux, é óbvio que ambos os SO's apresentam crescimento. O que é falacioso é dizer que o linux apresenta crescimento face aos unixes comerciais. A procura de servidores x86 é que aumentou. E digo isto precisamente porque em muitos casos as máquinas vêm virgens. Como referiste, só com os dados de suporte é que se saberia exactamente o que se passa. Quanto à IBM, o mercado mainframe/midframe é tradicionalmente lento; ainda é demasiado cedo para ver se a adopção do linux é feita com sucesso ou não. O que é certo, é que vão deixando várias opções de oferta na maioria das gamas. Se o linux ganha ou não lugar de destaque, só o futuro o dirá, e no mundo das TI o que hoje é amanhã já faliu, por isso só esperando para ver :) Em relação ao VMS, ganhou um novo fôlego após o atentado de 11 de Setembro, não só pela publicidade gerada pelas empresas que tinham datacenters no edifício - e que continuaram a operar, mas também pela (so called) ameaça global do terrorismo. O OpenVMS continua a ser único nas características de clustering e disaster recovery. Além disso, é considerada a plataforma mais segura que existe. Não consegui encontrar o link, mas há uns tempos li um artigo (relativamente recente) em que referiam um crescimento da ordem dos 18%.
|
| | | | | Bem, uma vez que nenhum de nós tem números vamos ficar a discutir indefinidamente a questão do Linux no midrange. Vamos acordar em discordar. :)
Mas no segmento dos mainframes as afirmações da IBM são claras: se bem me lembro, este foi o primeiro ano desde há uns 11 que a IBM verfificou crescimento nas vendas de mainframes novos. E segundo eles, o mérito vai para o Linux. Bem, lá único o VMS é. :-) Mas há alternativas com caracteristicas de RAS comparáveis ou melhores. E não foi o único a ser beneficiado pelo 11/09.
Mas as pessoas que compram brinquedos destes querem mais que bom hardware. Querem futuro.
A HP está a transmitir a ideia de que quer enterrar os Alpha o mais rápido possivel (suporte incluido), logo os potenciais clientes ou esperam pela versão para Itanium ou olham para as alterativas. Tens os NonStop dentro da própria HP, que dão a ideia de uma transição mais suava para Itanium, os zSeries da IBM que dão a ideia que vão continuar a correr código dos anos 60 por mais 40 anos, e provavelmente outros que nunca hei de conhecer.
|
| | | | Só uma opinião pessoal: atrás do enterro dos Alphas, vai o Tru64, que para mim é uma das coisas mais estúpidas à face da terra... Eu gostava imenso da combinação Tru64/Alpha (até porque Tru64 não corre em mais CPU arch. nenhuma :P), mas depois da aliança da Compaq/HP eu deixei de acreditar no futuro dos Alpha..
|
| | | | O futuro dos Alpha foi comprometido antes de eles aparecerem sequer no mercado. :-(
A decisão de descontinuar o Tru64 em favor do HP-UX ainda se compreende (dois galos no mesmo galinheiro...). Mas parece que nem estão a aproveitar devidamente a tecnologia. Exemplo Enfim.. a ver para onde isto vai..!
|
| | | | O futuro dos Alpha foi comprometido antes de eles aparecerem sequer no mercado. :-(
Como assim? Eu sempre tive a impressão que os Alpha durante a época da DEC, tiveram grande sucesso... apesar do preço elevado. Uma das grande vantagens dos Alpha era a performance do FPU como foi demostrado pelos benchmarks da SPEC. Mas enfim, isto são apenas gostos meus, o mercado não se gere por gostos.
|
| | | | Nem por isso. Apesar do reconhecimento técnico, nunca venderam bem. A DEC fez uma transição tardia e má para os RISC.
Os PA-RISC da HP datam de 1985, mas a DEC só lançou um produto RISC em 1989. Eram umas workstations que deixaram muita gente a babar-se, mas eram baseadas em MIPS. Mas os clientes que compraram produtos baseados em MIPS (que nunca tiveram VMS) ficaram um bocado queimados com a DEC quando eles introduziram os Alpha em 1992 e isso afastou clientes. Além disso, muitos clientes então já tinham adoptado outras arquitecturas e os PA-RISC ainda lhe faziam concorrência em performance.
|
| | | | O Tru64 realmente tem muitas coisas interessantes, mas confesso que não me impressiona. Confesso que a minha experiência nisto se resume a duas migrações, mas no mesmo hardware (um Alphaserver ES40 e uma Alphastation XP1000) o Linux conseguiu deixar no pó a instalação de Tru64 que lá estava antes, no que se refere às aplicações de number crunching que lá correm (nota: o compilador é o mesmo).
--
Carlos Rodrigues
|
| | | | | Os valores que mencionei foram retirados deste artigo , mas considero mais que razoável (e cordial) ficarmos pelo acordo de não concordar :) Quanto ao VMS, permite-me discordar, em termos de disaster recovery não existe equivalente. Acredito que o mercado priveligiado do OpenVMS não são os novos utilizadores, mas clientes que já tiveram ou possuem sistemas VMS, mas tendo em conta os valores referidos em vários sites, e a fidelização dos clientes ao VMS, bem como a relutância de mudar, acredito que a HP se encontra a reavaliar a continuidade do sistema.
|
| | | | | Um pequeno detalhe, embora não seja relevante para a discussão: a Gartner faz umas diferenciações meio desatualizadas. Assim, um IBM pSeries é capaz de acabar na categoria de "Unix Servers" enquanto um iSeries acaba na de "Midrange Servers". Fazia sentido à uns anos mas hoje.. :) Começando pelo fim: que o VMS terá futuro, é certo, segundo os planos da HP. Se bem que os planos da HP também incluiam portar o TruCluster para HP-UX e ...
O problema é que o VMS que podes comprar hojem em dia corre em Alpha. O último Alpha foi lançado, um tanto relutantemente, há uns dois meses. E creio que HP só garante disponibilidade de CPUs até 2009. Pouco tempo para os potenciais clientes interessados num VMS. Para teres uma ideia, a Intel vai continuar a disponibilizar Pentium II até ao ano que vem..
Logo, eles esperam pela versão para Itanium. Ou compram outra coisa.
Quanto a fiabilidade, o VMS fica atrás dos NonStop e zSeries. Mas há uma diferença crucial: os NonStop e zSeries baseiam-se em hardware exótico q.b. O VMS funciona em hardware mais vulgar. E talvez seja mais transparente às aplicações também, mas isso é especulação minha.
|
| | | | About SMP: para além de toda a questão big iron vs cluster de máquinas independentes, os CPUs estão a evoluir na direcção de multi-threaded/multi-core. Os Pentium4 com Hyperthreading são só o principio (não que tenham sido os primeiros). It's use it or loose it.
|
| | | | em breve vou publicar pelo NetBSD-PT umas benchmarks feitas entre NetBSD 2.0, OpenBSD 3.6, FreeBSD 5.3, Linux 2.4.28 e Linux 2.6.9, nos mesmos moldes (utilizando até o mesmo código) que se fez aqui.
apesar de relativa, a abordagem será similar à utilizada no site referido, sendo que é um meio, mais uma vez relativo, de conhecer certas tendencias de performance dos kernels comparados.
--
patrocionado por: Kmos, o criminoso! |
| | | | | " Pois, mas isso é no Linux, que tem uma base de contribuições gigantesca e aberta. Nos BSDs já não é assim, as equipas são normalmente mais pequenas e fechadas."
A tua critica, intencional ou nao, peca por base, estas a comparar sistemas operativos com kerneis e essa e' a falacia inicial com que muitos newcomers (aos BSD's) se deparam.
A cadeia de aprovacoes e contribuiçao de codigo, podera parecer mais restrita nos BSD's mas tenta la tu integrar uma distro qualquer de linux (sim porque e' de distro que estamos a falar), na mandrake, redhat ou mesmo gentoo e slackware e ve ate onde podes ir ao nivel de contribuicoes e alteracoes de linhas orientadores da filosofia do projecto.
Agora uma coisa e' garantida, mais valia e pessoas capazes em ambos os projectos dos BSD's tem sempre lugar.
Ser um commiter do FREEBSD alem do reconhecimento e notoriedade tecnicas e' garantia de emprego em qualquer parte do mundo. E isso, verdade seja dita, so esta ao alcance de muito poucos.
paulo trocas as chaimitezzz (santinho) e os pandur0S do exercito...YMCA! vamos brincar aos napoleoes e aos marinheiros.. YMCA!! YMCA!! |
| | | | | Não estamos a falar de distribuições mas sim da release de referência. Na maioria do software Livre™ cada programa tem um projecto informalmente aceite como referência. Qualquer um é livre de pegar nisso e usar e modificar, que é o que as distribuições de Linux fazem. Também há uma distribuição comercial de FreeBSD.
Geralmente, tudo o que aparece na referência tende a aparecer nos derivados. Por isso, a questão não é a dificuldade de integrar directamente numa distribuição X ou Y (o que pode ser razoavelmente simples a tão complicado como convencer o Theo a mudar a filosofia do OpenBSD) mas sim no projecto de referência. Claro que há casos em que a distribuição é a referência, mas há uma base substancial de software em que a referência é relativamente receptiva. Suficiente para fazeres a tua distribuição, se for caso disso.
|
| | | | Desatualizadas em que sentido? No sentido que não achas que o desenvolvimento de um SO se deve cingir demasiado a elas ou no sentido de que os projectos já não se cingem tanto a elas?
|
| | | | Simplesmente acho que um sistema operativo, como bloco de software tão extenso que é nao se deve ficar por executar só a tarefa X ou Y e ficar-se por aí.
|
| |
|
