Uma das perguntas recentes sobre possíveis motivos para usar o Solaris em um servidor. Eu gostaria de perguntar sobre o contrário:
Quais seriam os motivos para ficar longe do Solaris em um servidor?
O gerenciamento de pacotes e patches vem à mente, mas tenho certeza de que há mais. Você também pode apontar vantagens de outros sistemas operacionais de servidor em relação ao Solaris.
Respostas:
Eu sou (era) um administrador do Solaris até nove anos atrás, da v2.5 à v8. Eu tive uma pequena exposição ao Solaris 9 e quase nenhuma a 10.
Minhas razões para evitar o Solaris:
O suporte a hardware não é tão bom quanto muitos sistemas operacionais Linux ou Windows. Está melhorando.
Você pode executar o Solaris gratuitamente, mas não pode obter atualizações gratuitamente. Nem mesmo atualizações de segurança. Nem mesmo explorações de 0 dia. Você precisa comprar um plano de suporte, por sistema, que pode ser caro. Isso significa que a maneira de obter atualizações é aguardar a próxima versão "U" e atualizar nesse ponto.
O OpenSolaris é muito importante para mim. Ele muda com muita frequência, e os lançamentos vagam muito perto de instáveis ou não confiáveis para minhas necessidades.
Entre o Solaris e o OpenSolaris, a Sun conseguiu perder totalmente o meio termo entre "bem-vindo a 2004" e "sou tão novo e brilhante que não trabalho 100%!"
Eu estava disposto a usar o Solaris mais antes da implantação do projeto Blastwave. Por lá, eu pude obter ferramentas mais novas que se encaixam mais na maneira de fazer Linux (que é onde passo 95% do meu tempo profissional) com uma maneira on-line relativamente fácil de gerenciar as ferramentas e atualizações. Depois que a Blastwave e a CSW se acalmarem, examinarei os dois remanescentes e decidirei se vale a pena dedicar tempo e esforço a eles novamente. Realmente, a perda do Blastwave como uma fonte confiável de ferramentas foi um grande golpe para a viabilidade do Solaris em meus círculos.
Mas a razão número um para mim é que, no momento, não preciso fazer nada que exija Solaris.
Minha maior preocupação, como um grande cliente da Oracle, é que eles acabem com o Solaris ou o 'Oracle Enterprise Linux' (sua reformulação do RHEL).
Obviamente, ambos têm seus benefícios e suas desvantagens, mas eu sei que eles estão vendendo muito mais contratos de suporte de OEL do que a Sun estava vendendo para Solaris e, é claro, eles são os proprietários dos custos de desenvolvimento do Solaris.
Todos nós amamos o Solaris, mas se ele não estiver vendendo bem o suficiente e custando muito para ser desenvolvido, tenho certeza que a Oracle simplesmente o removerá dos ativos (manterá o ZFS etc.) e o venderá para outra pessoa. Essa seria minha principal preocupação.
Por 10 a 15 anos, a maior preocupação tem sido com o futuro da Sun e o futuro da SPARC. Eu estava prestes a desistir quando eles lançaram o Solaris 10, que avançou em termos de tecnologia (embora demorei ~ 1 ano para ser digno da produção). A recente compra da Oracle adiciona muita incerteza a curto prazo, mas isso pode desaparecer rapidamente (independentemente do resultado). O SPARC ainda parece uma causa perdida, embora tenha havido muita agitação em torno de seus "novos" processadores CoolThreads, mas eles são especializados demais para obter ampla aceitação.
Será interessante observar as tendências do setor ... Anos atrás, observei muitas empresas de Wall Street migrando para o Linux (do Solaris / sparc) não no Linux, mas no x86. Quando o Solaris 10 foi lançado, houve definitivamente uma reversão parcial para o Solaris, novamente no x86.
O gerenciamento de pacotes e patches não deve ser uma preocupação, é uma questão de conhecimento / habilidade. Para oferecer uma perspectiva diferente, meu novo trabalho é em um ambiente Linux e o gerenciamento de pacotes e patches me preocupa. Essas são preocupações genéricas antigas para as quais existem respostas.
Sentirei muita falta do Solaris, algumas coisas nele não podem ser encontradas em outro lugar.
A única razão pela qual posso sugerir é a "falta" de suporte / informações disponíveis na Web, se você não é um especialista em Solaris (comparado ao Linux ou FreeBSD).
Comparar o Solaris 10 ao Linux é de maçãs para laranjas. Principalmente, a diferença está no ambiente de construção, como qualquer pessoa que tenha movido aplicativos Linux para Solaris pode atestar. Eu esperaria que a Oracle se concentrasse em criar o modelo de compatibilidade de aplicativos / fontes Linux versus tentar posicionar o Solaris como um substituto para o Linux. O Linux também não substitui o Solaris!
Para aplicativos pequenos, o Linux é bom; para aplicativos incorporados, provavelmente é melhor. Para grandes aplicações Iron, o Solaris está em uma classe diferente de qualquer distribuição Linux. Examine a pilha TCP / IP, o agendamento em tempo real, o gerenciamento de serviços, a virtualização (zonas) à prova de balas do Solaris e você tem um superconjunto de funcionalidades em relação ao Linux. Adicione ZFS, DTRACE e PROGRAMAÇÃO MULTI-THREAD e você estará em uma classe de sistema operacional totalmente diferente.
O Linux é ótimo, eu adoro isso. Solaris é ótimo, eu também adoro. Cada um tem suas vantagens e desvantagens. A Oracle certamente não construirá seus produtos de ferro grande, como EXEDATA2 no LINUX, quando tiver um produto superior para grandes ambientes de ferro no Solaris.
Quando meu host de servidor compartilhado passou do BSD para o Open Solaris, a prisão por FTP desapareceu. Não sei se o bloqueio de FTP pode ser disponibilizado no Open Solaris usando um servidor FTP diferente ou talvez reconfigurando o servidor FTP padrão.
Os autores da página wiki da Joyent sobre o problema atribuem o problema ao getcwd .
trabalho no Solaris desde 2002 (há 15 anos) e tudo o que posso dizer é que esse foi o meu sistema operacional "favorito" por todo esse tempo, em particular por sua estabilidade e estabilidade com aplicativos comerciais conhecidos, como networker, oracle (quando ainda era dom), netbackup e assim por diante.
mas é mais uma "paixão" pelo Solaris do que qualquer outra coisa.
depois de 15 anos, para mim os "principais problemas" (se podemos chamá-los de problemas) foram:
a falta de documentação on-line em comparação com outros sistemas operacionais (em particular ao tentar depurar o desempenho do sistema), mas era melhor quando o Solaris 10 chegou. em particular para serviços de infraestrutura como LDAP, kerberos, NIS2LDAP etc. todos os sistemas foram documentados separadamente, mas você nunca conseguiu encontrar uma boa documentação com pessoas implementando tudo de uma só vez.
correções / atualizações (minha empresa teve que desenvolver seu próprio sistema de correções para Solaris)
a falta de ferramentas / binairies compatíveis on-line (muitas vezes tivemos que compilar nossos próprios e raramente encontrar binairies pré-compilados)
as dificuldades para entender problemas de desempenho às vezes devido à falta de boas ferramentas (solaris não é para iniciantes que tentam entender como o sistema funciona) e seu gerenciamento de memória específico (em particular quando usado em conjunto com bancos de dados oracle e tudo o que usa memória compartilhada)
por outro lado, o Solaris ainda é meu sistema operacional favorito até agora por vários motivos, alguns deles são:
nunca experimentei o Solaris 11, mas parece ótimo e não teria nada contra isso. Estou acostumado ao Solaris 10 (ainda o usamos intensamente onde trabalho) e ao RHEL agora (o que também é ótimo, mas completamente diferente) O RHEL é o caminho mais fácil a seguir ... se você não quer lutar e você deseja encontrar soluções na página 1 do google quando tiver problemas.
Solaris é bastante instável. Brincar com as filas de mensagens POSIX causa muitos comportamentos não documentados. Por outro lado, o Linux funciona como um encanto, sem problemas.
EDIT (após 1,5 anos de pesquisa e testes): OK, pessoal, talvez o Solaris não seja tão ruim. O problema é que errno.h por padrão não é seguro. Assim, recebo erros aleatórios de outros threads. Portanto, precisamos definir _REENTRANT, _TS_ERRNO ou _POSIX_C_SOURCE - 0> = 199506L para garantir a segurança do encadeamento. Observe que em outros sistemas operacionais, errno por padrão é seguro para threads. Assim, causa confusão.
mq_receive()retorna ssize_t, NÃO int . Eles não são os mesmos. Segundo, por 7.1.3 Identificadores reservados do Padrão C : "Todos os identificadores que começam com um sublinhado e uma letra maiúscula ou outro sublinhado são sempre reservados para qualquer uso". O código Enduro / X é repleto de identificadores reservados. Se você for um idiota pedante apenas porque um sistema operacional retorna um documento não documentado errno, provavelmente não deve escrever um código que não atenda aos padrões.