Resolvi colocar aqui algumas informações que tive acesso recentemente e que acredito podem ajudar no processo de elaboração das propostas de projeto. Façam suas críticas.Dicas para uma boa migração de Windows para LinuxMigração Planejada (p…

Compiere ainda não substitui SAP, bem como PostgreSQL ainda não substitui Oracle nem DB2.

Substituem sim — não sempre, mas em muitas ſituações. Mas o inverſo é também verdadeiro: tem muita ſituação, em várias empreſas, onde o Oracle e o DB2 não ſubſtituem o PoſtgreSQL, e onde o SAP não ſubſtitui o ADempière. E já presenciei algumas deſtas. Por exemplo quando não ſe tem rios de dinheiro.

Talvez um dia substitua. Para constatar isso te convido para um desafio:

Tenha um megafone na mão e fique de pé em uma cadeira no calçadão da Av. Paulista às 12:30 de qualquer dia útil. Peça para levantar a mão quem conhece Compiere, e quem conhece SAP. Faça o mesmo com PostreSQL e Oracle e DB2. Conte e publique o resultado.

E ißo prova o quê?

Não me reſponda com generalizações ſobre ‘empreſas’ — há as tais de todos os tamanhos e formatos, e nada ſerve para todas. O que me dá bronca em generalizações como as tuas é que, talvez porque a IBM ſeja cara demais para qualquer empreſa que não ſeja quaſe tão enorme quanto ela própria, você fala coiſas que ſão verdadeiras apenas ou principalmente para grandeßíßimas empresas. Nem todo mundo preciſa de Oracle e SAP, ergo nem todo mundo preciſa duma ‘Enterpriſe’ da vida.

Debian é tão superior às outras distribuições enterprise quanto o molho de tomate de minha mãe é superior ao de sua mãe. Isso é obviamente uma coisa bizarra de se falar, porque você com certeza prefere o molho de sua mãe.

Tudo isso para dizer que distribuição é uma questão de gosto, e isso com certeza vai definir qual delas você vai escolher para rodar na sua casa, mas esse parâmetros não são os mesmos quando uma empresa precisa dicidir tal coisa para rodar seu negócio.

Empresas não querem nem precisam usar coisas proprietárias. Elas gostam de Padrões Abertos. Mas isso é um detalhe que é em geral vencido pela sua necessidade de acesso a inovações. E observa-se hoje que as inovações infelizmente ainda nascem proprietárias. Só depois elas são reimplementadas com Open Source. Leia isto.

Compiere ainda não substitui SAP, bem como PostgreSQL ainda não substitui Oracle nem DB2. Talvez um dia substitua. Para constatar isso te convido para um desafio:

Tenha um megafone na mão e fique de pé em uma cadeira no calçadão da Av. Paulista às 12:30 de qualquer dia útil. Peça para levantar a mão quem conhece Compiere, e quem conhece SAP. Faça o mesmo com PostreSQL e Oracle e DB2. Conte e publique o resultado.

Empresas compram produtos ou serviços de TI baseado nesse parâmetro mais do que em sua veia técnica. Fazer de outra forma é como misturar religião com política, coisa que não dá certo.

Agora, se você usar o megafone para perguntar sobre Linux e Windows, o número de braços levantados vai ser +/- igual. É por isso que Linux, mas não todo o Open Source, está pronto para as empresas.

Entretanto, você preßupõe que ‘as empreſas’ querem ou preciſam uſar informações proprietárias. Ißo foi muito verdade, mas deixa de ſê‐lo a cada dia. Você eſtá careca de ſaber, mas em vez de Oracle uſa‐ſe PoſtgreSQL; em vez de SAP, ADempière; em vez de programas da IBM… muitos.

Ou ſeja, antes de penſar na diſtro, temos de penſar no negócio. Para quem já tem um legado, realmente a única opção hoje é uma Enterprise da vida; mas para quem começa, as ‘Enterprises’ ſão uma péßima eſcolha, não ſó pelo cuſto mas por ſerem tecnicamente inferiores às diſtros baſeadas em Debian.

O teu artigo tem eße problema ſeríßimo de preßupor que ſe preciſa de uma Enterpriſe porque ſe vai uſar programas proprietários, em vez de moſtrar que na verdade têm‐ſe alternativas, e que aliás os programas proprietários têm eße defeito de não ſuportar boas diſtros.

Eſtá na hora da IBM ſuportar o Debian em ſeus programas como já ſuporta em ſeus ſervidores — embora não tão bem quanto a HP o faz, ſem preciſar de aditivos de contrato.

Suporte em geral é local, e você sim pode adquirir suporte local para qualquer distribuição. Mas isso não é tudo. O mais importante para empresas é escolher um SO que seja suportado pelas aplicações que ele precisa rodar com elas (Oracle, SAP, SW da IBM, etc) e o HW no qual ela precisa rodar tudo isso (IBM, HP, Dell, etc).

Como delineei no artigo, suporte não é só ter para quem ligar. Suporte está relacionado a ter um ecossistema completo de gente e outros produtos que interoperam com garantias comerciais.

Usar distribuições gratuitas como Debian ou Slackware, e adquirir serviços de suporte de uma companhia local, independente
Isso pode trazer mais risco por causa da operação de suporte não-global, e falta de integração entre o empacotamento do software e seu suporte, o que leva a um ecossistema fraco ou inexistente de ISVs e IHVs.

Na verdade a operação de suporte pode ser global, como no caso da HP (que suporta Debian no Proliant) e da própria IBM (que suporta Debian e também Ubuntu). E na verdade ißo pouco importa: as neceßidades de suporte sempre são locais.

E a afirmação sobre falta de integração entre empacotamento e suporte é puro mumbo‐jumbo — não existe essa integração em parte alguma, nem nas distros ‘Entreprise’.

Mas não é só pra reduzir o risco que podemos pensar em contratar suporte para uma distro. Como você mesmo apontou, há software e hardware de terceiros que só são homologados para as distros “enterprise”. A Oracle, por exemplo, só suporta seus produtos quando rodam sobre uma distro enterprise para a qual seu cliente tenha contrato de suporte. Esse é um forte fator determinante na decisão de escolha de uma distro. Na minha experiência, ainda mais forte que o fator de redução de risco.

O problema que ocorre quando começamos a usar as distros enterprise é que elas entram pelos servidores críticos e acabam se estabelecendo como padrão para todos os servidores. Daí, acabamos contratando suporte para todas as máquinas, mesmo para aquelas que não se justificariam de acordo com os dois fatores acima.

Uma saída muito interessante pra essa situação é usar a distro enterprise somente nos servidores que justifiquem o gasto (pela criticade do serviço ou por força de homologação) e adotar uma distro clone nos demais. No caso do Red Hat Enterprise, o clone mais interessante que conheço é o CentOS. Não conheço clones do SLE.

Esta estratégia permite manter um parque de servidores uniformes e mantendo a opção de só gastar no que for absolutamente necessário.

• Nem SEMPRE é desejável manter uma instalação constantemente atualizada. Se algo está funcionando como deve, dificilmente alguém vai mexer. As pessoas fazem upgrade por 2 motivos: porque alguma coisa não está funcionando direito, e porque a instalação atual não tem mais suporte.
• Dizer que .deb é melhor que .rpm é uma opinião sua. É como dizer que distribuição X é melhor que distribuição Y. É melhor em que? Tecnicamente ambos são equivalentes, com as mesmas funcionalidades. Conselho: não deixe o gosto pessoal interferir tanto no que é melhor a longo prazo para uma empresa.
• Sobre disponibilidade de software, empresas procuram isso de forma suportada, ou seja, darão preferência a distribuições que são suportadas pelas aplicações de negócio que elas precisam rodar. As aplicações de negócio é quem determinam a infraestrutura, não o contrário.
• Suporte a longo prazo é importante, mas não é tudo. Bom ecossistema costuma ser mais importante porque seu resultado é um suporte mais consistente ainda, em mais longo prazo. Ubuntu começou a oferecer suporte comercial, mas ainda não tem um ecossistema comercial formado. RHEL e SUSE tem os dois.

Por isso, quero dizer, qual sistema é mais fácil de manter atualizado e funcional. Nesse sentido, acredito que as distribuições .deb tem alguma vantagem com relação as .rpm.

Outro aspecto é a disponibilidade de software. Geralmente não estamos procurando um servidor de http://FTP. Queremos software bastante específicos. Quanto mais software fora da distribuição precisarmos, menos coberto pelos updates e a integração estaremos.

Por fim, quais distribuições oferecem políticas claras de suporte de longo prazo aos seus produtos?
A iniciativa do Ubuntu, com o seu LTS, mostrou que, mesmo uma distribuição “suportada” pela comunidade, o importante é definir metas claras e transparentes, inclusive para que a empresa possa se programar.

Alguns SRPMs do SLES, principalmente de outras plataformas, não estão disponíveis para download público. Por exemplo, nunca consegui encontrar o SRPM do Kernel da plataforma iSeries ou zSeries, e assim por diante.

Os codigos fontes do SLES tambem estao disponiveis para quem compra, assim como os codigos da rhel

Os pacotes fontes do kernel no SLES tambem sao os mesmos para diferentes archs…

Ta meio outdated seu quadro ai