Arquivo
Razões para nem começar a usar o Scientific Linux
Hi guys,
Esse texto é uma carta aberta ao Henrique LonelySpooky a respeito do CentOS, distribuição que utilizo em meu desktop e meus servidores. Não é segredo pra quase todos que eu também estou deixando o CentOS. E esse texto do LonelySpooky brifa explica por alto alguns motivos que também o levaram abandonar essa distribuição. Mas o Scientific Linux, no meu caso, não será uma resposta, e sim uma pergunta. A resposta será “Não”. E eu explico o por quê.
Onde eu discordo da Opinião do LonelySpooky
De 2009 para cá, pouca coisa mudou na realidade: o CentOS tem milhares de usuários, mas apenas “meia dúzia” de desenvolvedores que decidem tudo. Não existe, de fato, uma Comunidade CentOS porque a Comunidade não participa efetivamente na construção da distro. Detalhes como papel de parede, tema, publicidade e empacotamento se passam praticamente às escuras ou dispersos em páginas lúgubres e mal divulgadas.
Henrique, como bom usuário CentOS que és, você deveria lembrar que o desenvolvimento do CentOS realmente não é interativo via website ou fórum. No entanto a comunidade participa sim, através das listas de discussão onde todas essas coisas são debatidas. E nada disso é mal-divulgado, o problema é outro (explico mais pra frente).
Quando o Red Hat Enterprise Linux 6 foi lançado eu já acompanhava ávidamente as versões de teste e creio que muita gente, assim como eu, acreditava que um RHEL mais novo abriria um importante leque de possibilidades; afinal de contas, o RHEL 5.x é baseado no jurássico Fedora Core 6, com o qual diversas aplicações recentes são incompatíveis.
Na verdade, as incompatibilidades nesse aspecto só são dos pacotes pra desktop. Quem usa RHEL/CentOS 5 sabe que, apesar do kernel ainda ser o 2.6.18, ele é muito bem patcheado para assegurar a compatibilidade com o hardware mais recente. Empresas desenvolvem software para outras empresas. Logo, nos softwares que continuam sendo desenvolvidos para o RHEL 5, não faz diferença a última versão do kernel, do GCC ou da GLibc.
Em vez de uma solução, o RHEL 6 evidenciou um problema muito grave que a Comunidade CentOS enfrenta. A reduzida equipe de desenvolvedores encontrou-se espremida entre duas releases: RHEL 5.6 e RHEL 6.
Houve votação nas listas para eleição da prioridade. Inclusive, eu votei na prioridade de lançamento do CentOS 5.6 ao invés do CentOS 6, uma vez que precisarei homologar toda minha plataforma que hoje roda no CentOS 5.x para rodar no CentOS 6, enquanto o CentOS 5.6 é versão de continuidade, não de recomeço. 😉
Onde eu concordo com a opinião do LonelySpooky
De 2009 para cá, pouca coisa mudou na realidade: o CentOS tem milhares de usuários, mas apenas “meia dúzia” de desenvolvedores que decidem tudo. Não existe, de fato, uma Comunidade CentOS porque a Comunidade não participa efetivamente na construção da distro.
Eu concordo em parte com essa afirmação. Não acho que a equipe que desenvolve o CentOS é pequena, pelo contrário. Acho ela até abastada.
O que não gosto é que o desenvolvimento do CentOS me passa a impressão de ser feito “em panela”. Isso é, sempre as mesmas pessoas, e o ego das referidas é um tanto quanto exaltado. Isso não é uma exclusividade dos desenvolvedores do CentOS, mas sim um problema de TODAS AS DISTRIBUIÇÕES feitas em comunidade. No Debian é a mesma coisa, a diferença são as intermináveis votações.
Como atenuante, numa distribuição como o CentOS não são necessários tantos desenvolvedores, uma vez que o CentOS é basicamente um repackage do RHEL. As listas são abertas até certo ponto, e a burocracia para participar do desenvolvimento é tanta que eu optei por não distribuir os pacotes que eu já fiz nesses meios oficiais.
Diante da impaciência da comunidade, que por várias vezes solicitou mais transparência sobre o status do CentOS 6, a resposta padrão é sempre a mesma: “O CentOS 6 ficará pronto quando ficar pronto”
Isso, infelizmente, tem sido um problema seríssimo e dispensa comentários.
Razões para continuar no CentOS
Apesar disso tudo, o CentOS ainda tem um nome muito forte nos provedores da vida. Nome erguido por mérito. E existem pessoas que não estão inteiradas dos problemas que a comunidade CentOS está enfrentando. Pessoas essas cujos servidores continuarão funcionando e não tem interesse ou disponibilidade de ajudar na distribuição. Pessoas que não se importam em esperar e que não querem se envolver. Você é uma dessas pessoas? Ok, continue no seu CentOS. Admito que em muitos lugares também vou continuar.
Razões para não continuar no CentOS
Desde o lançamento oficial do RHEL 6, o desfile dos egos nas listas do CentOS tem se tornado extremamente desagradável. Me lembro da “data de lançamento” já ter sido marcada e descumprida umas quatro vezes. E ao invés de todos arregaçarem as mãozinhas e empacotar, o development team parece estar mais preocupado em discutir o sexo dos anjos nas listas da distribuição. Muitos questionam a entrega do CentOS 5.6 e 6, sugerem fusão entre o Scientific Linux e o CentOS ou uma colaboração mútua, oferecem ajuda, mas tudo vira motivo para a trollagem fluir. E o tempo passa. E nada do CentOS 5.6 e 6…
Minha história com o Scientific Linux
O Scientific Linux também é um clone do Red Hat Enterprise Linux com bastante qualidade. Assim como o CentOS, ele não é exatamente igual ao RHEL (se você, usuário CentOS, diz que o RHEL é idêntico ao CentOS, certamente você nunca usou o RHEL). Utilizei-o na versão 5.3 quando tirei o Fedora do meu desktop. Desde o momento que o instalei, reparei que o Scientific Linux é mais organizado que o CentOS, tem mais pacotes e tinha opção de usar XFS na / (que o RHEL só adicionou na versão 6!). A arte era mais feia – beeem mais feia – que a do CentOS, na minha opinião, mas troquei o papel de parede minutos depois.
Apesar de todas essas qualidades, percebi que a comunidade do Scientific Linux não levava as atualizações do sistema muito a sério, e algumas falhas que eram corrigidas bem em em tempo no CentOS acabavam demorando muitos dias mais para serem corrigidas no Scientific Linux. No ato da instalação, quando o fiz, a versão 5.3 havia acabado de ser lançada, e o CentOS 5.3 já estava em meia vida, com o RHEL 5.4 quase pronto. Isso me jogou um balde de água fria, e quando o CentOS 5.4 foi lançado, alguns meses depois, chutei o Scientific Linux 5.3 e voltei para o CentOS.
Essa demora extra no ciclo do Scientific Linux eu continuei acompanhando e confirmei nos releases seguintes. No entanto, o que parecia impossível, aconteceu com o CentOS. E nesses últimos dois releases, até o CERN/Fermilab (que também demoraram para lançar o Scientific Linux 6) conseguiram ser mais rápidos que o CentOS.
Mas, cansado da espera pelo novo CentOS 6, cogitei novamente a minha volta para o Scientific Linux.
A continuidade em outro clone do Red Hat Enterprise
Quando eu estava quase concretizando a instalação do Scientific Linux, li essa thread no LinkedIn onde outros usuários de CentOS reclamam da mesma questão que eu: Guerra de egos na disponibilização das versões, incógnita de tempo, demora exagerada e etc. E nessa mesma thread descobri o PUIAS Linux, outro clone do Red Hat mais antigo que o CentOS e mais fiel ao Red Hat original.
O PUIAS é desenvolvido pela universidade de Princeton, e desde que tenho o utilizado, o descobri como uma distribuição mais madura que o CentOS apesar de menor, que distribui rapidamente as atualizações do sistema operacional, e que ficou pronta bem antes do Scientific Linux 6.
O PUIAS não tem mídia de instalação (o usuário precisa cria-la se quiser instalar), ou realizar a instalação por rede como é meu costume. O fato de também ser desenvolvido por uma univerisade, que acima de tudo possui COMPROMISSO, me garantiu mais firmeza para experimentar, e estou a poucos passos de migrar meu desktop para o PUIAS 6. Basicamente só falta eu terminar de empacotar o KDE, cujo mesmo procedimento eu também precisei realizar no RHEL 6 e Oracle Unbreakable Linux 6.
Conclusões
Você está aguardando o CentOS 6 ou um bom clone do Red Hat Enterprise Linux 6? Se a resposta for a segunda alternativa, experimente o PUIAS, você não tem mais nada a perder mesmo…
Atenciosamente,
Lucas Timm.
Recreating the suse/RHEL/CentOS initrd file
Things change. In an enterprise enviroment, sometimes we’re surprised adding a new hardware component inside a server and the Linux won’t boot up properly. Or maybe you’re just virtualizating (by P2V) a server and faced this problem too, once the original hardware isn’t compatible with the virtual infrasctructure provided by your new hypervisor. And the “Kernel Panic: Unable to sync VFS“, or just a single-user shell with a incomplete Linux kernel waiting for your action (as you would do something!) is the only thing you’re getting.
Luckily, it’s really easy to fix it.
The scenario
In my case I added a fibre channel card in some servers of my company. All the servers will now access my storage device, and the same storage is already configured to receive the servers’ requisitions.
All the servers will not boot from the storage device. They all will keep booting the OS from the local array and disks, but I need the lpfc.ko module loaded from boot to mount a few directories by fstab (a /usr/sag, a /u02 and a /u03 from an ADABAS and a Oracle servers).
I don’t need to reinstall the OS to solve this problem, I just need to recreate the initrd file and put the module inside it. To do this I will use the mkinitrd program, but the sintax is different to a Linux distribution from another…
So If I don’t update the initrd file, all the LUNs will be detected later by udev, and the respective services may crash by trying to start some applications without any data inside the pointed directories. And a disaster may occour.
The first system: A Suse Linux Enterprise Server 10.2
I think the suse’s mkinitrd it’s the easiest mkinitrd command I’d already tried. You can be sure by reading the manual with the “man mkinitrd” command. To do what we want, you need only to edit the /etc/sysconfig/kernel file using vi:
vi /etc/sysconfig/network
Now, look for the INITRD_MODULES line and add the module you need inside the quotes:
INITRD_MODULES=”lpfc ide-core ide-disk scsi-mod sd_mod scsi_transport_spi mptbase mptscsih mptspi piix ata_piix processor thermal fan reiserfs edd”
Backup your current initrd file: check your /boot/initrd symlink and backup the original initrd ramdisk. Just recreate the initrd file with the command:
mkinitrd -d /dev/sda2
(where /dev/sda2 is your root device. Check your /etc/fstab file or “mount” command)
If the command finished well, it creates a /boot/initrd-your-kernel-version-and-patches.img file. Update your boot menu (usually in the /boot/grub/menu.lst file) and reboot your server to test if your new hardware device was now detected correctly at boot. Quite easy, a piece of cake!
The another systems: A RHEL 5.5 and a CentOS 5.5 and 5.4
Now I’d just finished my suse server, there’s still a Red Hat (and based) servers waiting for the same update. In RHEL/CentOS and Fedora, there’s no /etc/sysconfig/kernel to mkinitrd read. mkinitrd will read the /etc/modprobe.conf and /etc/modprobe.d/* files, and the sintax is a quite different.
When everything works well, you just need to append “alias your-module your-module”, “alias your-module some-alias” or “install your-module /bin/true” in this file (/etc/modprobe.conf). So re-create the initrd using the following command:
mkinitrd -v -f /boot/your-new-initrd-file.img $(uname -r)
Warning! Pay attention on the text output: Sometimes the module isn’t inserted as it should! If mkinitrd did it, you’ll need to specify this module to mkinitrd by hand:
mkinitrd -v -f /boot/new-initrd.img $(uname -r) –with=lpfc
According the manual, with the “–with” tag, mkinitrd command include the specified module to load after all the SCSI modules. This is what I want, but maybe you need to load a driver before the SCSI modules subsystem. So replace the “–with” parameter by “–preload“.
Now your new initrd file is ready. Update your /boot/grub/menu.lst file and reboot your server to check if everything worked fine.
That’s all, folks!
Lucas Timm
Teste – Red Hat Enterprise Linux 6 Beta 1 e 2
Eu sei, eu sei. O RHEL6 Beta 1 saiu em Abril, e se não me engano, foi no dia 21 (não googlei pra confirmar). O Beta 2 saiu em junho, com uma atualização em julho. Mas estou trabalhando demais, e somente agora tive tempo para experimentar (e fazer uma análise) daquilo que virá. Testei as duas versões. As imagens ainda são baixáveis no FTP da Red Hat, tanto o primeiro quanto o segundo, e não se sabe até quando (provavelmente até o último estágio dos RCs, mas não é confirmado). O mirror é lento, e por isso o download é demorado. Apesar de tudo, tenho me divertido bastante na distribuição. Não quero ser pego desprevenido quando adquirirmos a versão 6 final e quando o CentOS 6 for entregue. Afinal, muitas coisas aconteceram no mundo Linux desde o lançamento do Red Hat 5 (que foi em 2007) pra cá.
Deixando de lero-lero. Gimme the tech specs!
As especificações são praticamente as mesmas do Fedora 12. Estou testando o RHEL6 como servidor, então, não instalei nenhum pacote oriundo do Fedora ou de repositórios externos. Então, o que obtive foi:
Kernel: 2.6.32-19.
GCC: 4.4-3
GLIBC: 2.11
Gnome: 2.28.2
X: 7.5.6
Yum: 3.2.27-12
BETA1 – Instalação e primeiras impressões do RHEL6
Após o download, criei uma máquina virtual no VMware vSphere 4.1. Setei o tipo da máquina virtual como “Red Hat Enterprise Linux 6 64-bit”, com quatro processadores, 4GB Ram e 20GB em disco. A imagem de instalação estava na mesma LUN do storage. Nesta definição, por padrão, o vSphere setou o driver de disco da máquina pra “VMware Paravirtual” e o driver de rede pra “VMXNET3”, algo que estranhei. Afinal, paguei pra ver se o driver de disco seria detectado na instalação uma vez que o “VMware Paravirtual” só costuma ser detectado após a instalação do vmware-tools, bem como o VMXNET3, cuja ausência me impediria de realizar uma instalação por rede. Instalação por rede, agora, não era o caso, então azar. Mas, chegou a hora da instalação e… Batata! Disco não encontrado – e nem a rede. Então, reconfigurei a controladora da máquina virtual pra “LSI Logical SAS”, reinicializei-a e a instalação aconteceu normalmente. Comecei com o pé esquerdo…
Mesmo assim, após isso, a instalação aconteceu às mil maravilhas. Não pediu serial como nas versões oficiais. Gostei da nova versão (?) do Anaconda, uma vez que ele ficou mais limpo, mais organizado e com um tema mais bonito. Entretanto, o particionamento ficou mais confuso. Não experimentei as opções padrão, e (como sempre), selecionei “personalizar”. Afinal, julgo o particionamento como a etapa mais importante da instalação. Todo o resto você repara depois via sistema, mas se o particionamento for ineficaz, ainda que use LVM, é mais trabalhoso (e arriscado) uma recuperação posterior.
Minha primeira surpresa foi agradável: Pela primeira vez, é possível instalar o RHEL6 oficialmente em XFS. Parece que finalmente a Red Hat escutou os clientes nesse aspecto, apesar de agora já existirem file systems mais modernos que este. Por default o sistema de arquivos recomendado é o EXT4, que foi o que utilizei. Criei uma /boot com 100MB, um Volume Group denominado “system” com 19.8GB e mais dois Logical Volumes: Um denominado “Swap”, de 512MB e outro denominado “root”, com o resto dos quase 19.5GB para montar a /. Não especifiquei /home, /var, /tmp ou /usr, pois nesse caso, pelo servidor ser virtualizado, não haverá sobrecarga de um ou mais discos (todos os volumes estão no storage, com RAID5, compartilhados com outras máquinas virtuais).
Prosseguindo a instalação, também gostei muito da nova organização dos pacotes. Unificou-se aquela burra divisão “Base” / “System” existente no Red Hat 5. Existe uma enorme (enorme!) quantidade de pacotes direto do DVD de instalação, mas isso se dá, provavelmente, pela distribuição ainda estar no Beta 1. No produto final, com certeza haverá a costumeira divisão de pacotes baseada em tipo de instalação (Server, Workstation e Virtualization). O resto foi automático, bastando setar a senha de root, timezone, hostname e etc. O sistema foi instalado perfeitamente e não achei nenhum bug.
Utilização
A primeira coisa que pensei após instalar foi: O sistema dá uma impressão de agilidade maior que o Red Hat 5. No entanto, o Red Hat 6 perdeu o bonito RHGB que o acompanhava na série 5, e disponível no Fedora de 6 a 9. Isso já era esperado, e ele foi substituído pelo Plymouth, que é mais flexível e também é bonitão, mas não carrega mais o X como o RHGB fazia, coisa que era legal pra fazer WinLoser pirar (“meu sistema sobe em modo gráfico e interativo, e o seu?“).
É, não dá mais. (Clica que aumenta!)
O desktop do Beta 1 continua com cara de Fedora, porém mais atual. Também quisera, né! 3 anos…
Instalei o VMware Tools, como de costume, que compilou absolutamente sem problemas. (No Red Hat 5 e CentOS 5, os módulos já não são mais compilados, uma vez que o instalador já carrega os módulos prontos pro kernel utilizado por ambas).
Sobre o BTRFS
Eu queria experimentar o BTRFS já nessa instalação, e não foi possível. Porém, após ler o draft do Migration Guide, verifiquei que existe uma opção à ser informada ao kernel e que disponibiliza o módulo do BTRFS para instalação. O uso é experimental, mas como estou usando pra “brincar”, deixei pra testar no Beta 2. Não iria reinstalar o Beta 1 “só” por isso. Se tiver mais um ou dois curiosos por aí, basta digitar “linux icantbelieveitsnotbtr”(wtf!?) ao selecionar o kernel no início da instalação.
BETA2 – Instalação e segundas impressões
Após dois dias de testes, chegou a hora de baixar o Beta 2 e acompanhar as mudanças que ocorreram nesse meio tempo. Ao chegar no mirror, surpresa: A mídia de instalação já havia sido modificada, e já disponibilizada como Server e Workstation. Baixei ambas, em versão do dia 15 de julho de 2010, mas até o momento, só fiz a instalação da versão Server. A Workstation eu utilizarei em algum desktop que eu achar sobrando por aqui.
As mudanças nessa versão se tornaram mais evidentes que na anterior. A interface gráfica foi alterada e está mais bonita. Passei a opção “icantbelieveitsnotbtr” pra testar o BTRFS, como deixei pendente no Beta 1, mas ao chegar no particionador, ainda não estava disponível. 😦
O Anaconda também ficou mais “a cara” da Red Hat. No instalador ele já solicita o cadastro da Red Hat Network para quem possuir uma conta de avaliação. Eu não tenho, então pulei essa parte. Todo o resto foi sem surpresas e sem alterações. Não reaproveitei nem o anaconda-ks.cfg da instalação anterior pra verificar se alguma feature foi alterada, e com exceção da RHN, não houve nenhuma outra modificação funcional, somente a arte. O nome “BETA” já não está mais tão estampado como no Beta 1, o que passa um ar mais sério ao sistema (apesar do WARNING) no início da instalação.
A mídia Server não está mais tão enxuta quanto o da série 5. Em comparação ao Beta 1, notei falta apenas do OpenOffice (que no Beta 3, se houver, provavelmente será substituído pelo LibreOffice), e cuja ausência é normal numa mídia de instalação Server. O Plymouth, por padrão, veio com um tema bem mais insosso que o do Beta 1, pra não dizer mais feio: apenas um anel girando durante o carregamento do sistema. Samara Morgan mandou dizer que a-do-rou. Eu não.
Alguns pacotes também sofreram atualização desde o Beta 1 (mesmo?). As versões de alguns deles:
Kernel: 2.6.44-1.
GCC: 4.4.4-10
GLIBC: 2.12-1.4
Gnome: 2.28.2
X: 7.7-17
Yum: 3.2.27-12
BETA 2 – Utilização
(Seven days.)
Após a instalação, configurei o yum habilitando os repositórios pro RHEL6 Beta, e instalei mais alguns temas pro Plymouth. Boot feio aqui não! Diferente do Beta 1, as pastinhas do Gnome agora são azuis e tem relevo. Déjà Vu? As ferramentas que ficaram foram as seguintes:
– system-config-authentication
– system-config-lvm
– system-config-date
– system-config-network (mas ela chama a system-config-network-tui)
– system-config-firewall (muitas alterações, eu gostei)
– system-config-kdump
– system-config-printer
– system-config-keyboard
– system-config-printer-applet
– system-config-kickstart
– system-config-services
– system-config-language
– system-config-users
O sistema já tinha um update de kernel disponível, e agora foi atualizado pro 2.6.32-44.2. As configurações do Apache continuam seguindo o (ótimo) padrão da Red Hat, o que vai garantir uma atualização tranquila para aqueles que seguem essa hierarquia. Pelo menos do ponto de vista do servidor web. Também não encontrei o gdm-setup, front-end que configura o gdm, em ambos os Betas, o que dificultou a configuração de login remoto diretamente via X.
Quebrando o gelo – RHEL5 x RHEL6
A primeira diferença que senti no Beta 1 foi ao configurar a interface de rede: CADÊ O SYSTEM-CONFIG-NETWORK? É um mundo cão, mas sim. Eles tiraram. 😦 Rapidamente fui ao system-config-services, encontrei o serviço de rede (network) ativo, corri pro /etc/sysconfig/networking e não encontrei nenhuma configuração de dispositivo. Segundo o draft de migração do RHEL5 para RHEL6, confirmei o que eu não queria ter visto: O system-config-network foi substituído pelo NetworkManager e seu nm-applet. Isso gerou conflito com os usuários, e algumas pessoas reclamaram no bugzilla a ausência do utilitário. Não deu outra, a comunidade venceu e a Red Hat reinseriu o system-config-network novamente na árvore do RHEL6. 😀 Mas, no Beta 1, não teve jeito. Fiquei sem.
De acordo com o mesmo documento (que está desatualizado), outras ferramentas de configuração também foram retiradas. Uma regressão no meu humilde ponto de vista. E isso se aplicou ao:
– system-config-boot
– system-config-network
– system-config-cluster
– system-config-http
– system-config-lvm (apesar que no meu, está instalado e funcionando bem. Sempre foi uma ótima ferramenta)
– system-config-netboot
– system-config-nfs
– system-config-bind (ok, era cheio de bug e eu preferia fazer na mão. Entendo que deve ser um saco parsear configuração do Bind. Mas não seria melhor ter consertado? Era uma ferramenta com muito potencial)
– system-config-samba
– system-config-soundcard (obsoleto por que agora o sistema detecta as placas de som automaticamente? Com o PulseAudio? Garanto, ESSA VAI FAZER FALTA).
– system-config-switchmail (obsoleto por que, segundo o manual, o novo MTA padrão é o Postfix. Comigo isso só se comprovou no Beta 2. No Beta 1 ainda era o Sendmail).
E outras ferramentas que foram reagregadas:
– system-config-securitylevel (melhorou, unificado no system-config-firewall)
– system-config-rootpassword (melhorou, unificado no system-config-users)
– system-config-display (essa melhorou, foi substituído pelo XRandr, que tem se mostrado excelente de um ano pra cá)
Eu entendo algumas das mudanças aí realizadas, mas são poucas. Bem poucas. Concordo que o system-config-http, system-config-nfs, system-config-samba e system-config-boot eram ferramentas extremamente básicas e sua manutenção levava tempo. Mas, se o RHEL já tem uma interface gráfica confortável de usar, não seria mais racional o incremento dessas ferramentas visando uma melhor integração do sistema como um todo? “mimimi eu só uso o modo texto” – Eu sei Flipper (Marcellus®), eu também. Mas ferramentas gráficas fazem MUITA diferença, principalmente pra gerentes, pseudo-administradores e alguns outros cargos administrativos. Os faz pensarem que sabem realizar qualquer tipo de configuração, tira a impressão de “modo texto é coisa do passado” (aham, fala isso pra IBM, CISCO, Oracle, Sun e etc) e dá um peso uma feature a mais pro sistema.
Das configurações que realizei, gostei do syslog ter sido substituído pelo rsyslog e já ter o plugin de integração com o PostgreSQL direto da instalação, é um dos meus principais recursos de monitoramento. Há vários plugins do Yum também disponibilizados direto dessa mídia. Outra alteração já prevista foi a adoção do upstart, existente no Fedora desde a versão 9, e agora trazida por padrão no Red Hat 6. Eu não gosto, mas humildemente entendo que é um caminho sem volta. Assim como em outras distribuições, as configurações do upstart ficam no /etc/init e disponíveis no man 8 init, man 5 init, e no caso dos Red Hats, /etc/sysconfig/init.
Testes que ainda vou realizar
Das coisas que realmente quero experimentar no RHEL6 são os novos recursos de virtualização, com a criticada e elogiada substituição do Xen pelo KVM. Eu realmente estou ansioso para testar o RHEL6 como hypervisor, pois desde o princípio, “fui mais com a cara” do KVM do que do Xen. Os motivos que tenho para isso são completamente pessoais, nem adianta vir com mimimi se você prefere o Xen. Eu sei usar bem a ambos, mas prefiro o KVM pela excelente integração com o kernel Linux em si, coisa que não acontece com o Xen. Isso não pode ser feito numa máquina virtual, então não posso testar por agora, mas vou aproveitar algum IBM x3400 que tenho sobrando aqui no trabalho desde que foram substituídos e brincar com a virtualização.
Considerações finais
Nenhuma. Tudo o que foi descrito foram conclusões minhas. Ainda tenho muita coisa pra testar, provavelmente escreverei outras coisas relacionadas a essa distribuição. Se você ficou com vontade de experimentar, aproveite a disponibilidade e faça os testes que julgar necessário. 🙂
Stay safe,
Lucas Timm.
Ajude a BetterPlace.org e ganhe uma cópia gratuita do SoftMaker Office
Conhecia? Eu também não.
Após informações dos velhos amigos do IRC (valeu Caio_Cesar!), fui conferir a suíte de escritório SoftMaker Office. A suíte de escritório tem versão nativa para Linux E Windows (também tem pra Windows CE). O software é proprietário E pago, então, os usuários babacas de software livre podem parar de ler por aqui.
Pros que continuaram: Os programas Planmaker (planilha eletrônica), Textmaker (editor de texto) e Presentation (slides) são de extrema qualidade, deram de 10 x 0 no desempenho e estabilidade ao manipular os documentos existentes no meu computador em comparação ao seu, digamos, concorrente. Tem formato próprio, além de suportar .doc/.xls/.pps, .rtf e ODF. Infelizmente NÃO suporta OOXML, nem tudo é perfeito. Também não é melhor que o Office 2007, que pra mim é absoluto. Mas pelo pouco que utilizei, concorre igualmente com o Office 2003. Suporta check-spelling em pt_BR e possui uma tradução DECENTE de TODOS os menus que testei. Nem é necessário reiniciar o programa ao mudar o idioma!
A versão pra Linux é um parágrafo a parte. Tem em RPM, é estável, rápida, elegante e bem integrada com o desktop. Abre em 2 segundos (JURO). Tem um visual meio KDE2, segundo o Caio_Cesar (eu não sou dessa época), mas o visual me agradou. É simples e intuitivo, com menus bem claros a respeito das opções. Tem alguns diálogos estilo Windows 9x/Wine, mas não sou fresco, e o que me importa é a funcionalidade.
O site da SoftMaker está com uma “promoção”. Qualquer pessoa pode se registrar gratuitamente e ganhar uma cópia gratuita do SoftMaker Office para uso perpétuo, ganha suporte gratuito e descontos no caso de upgrade para as próximas versões. Vale as versões pra Windows E pra Linux. De cada download realizado, a SoftMaker doará 10 centavos de Euro (não sei fazer o simbolozinho) para a BetterPlace.org, organização que ajuda uma penca de gente por aí (dá uma olhadinha no site, doa algo lá também!). Até o momento, 3.300.40 Euros já foram doados. Ou seja, tá fazendo sucesso. 🙂
Quer uma cópia participar? Clica aqui, cadastre-se, baixe, teste e divulgue. Aproveite antes que acabe, pois o FAQ não fala de datas!
Stay safe,
Lucas Timm.
Rede do CentOS 5.1 no VMware Workstation 6
Resolvido o problema que relatei nesse post (CentOS 5.1 sem rede no VMware Workstation 6):
Reinstalei a máquina CentOS 5.1 no VMware Workstation 6 em Windows, setando o tipo da máquina nas propriedades como “VMware Workstation 5”, macete que faz meu CD do Windows 2000 4×1 instalar, e funcionou perfeitamente! Feliz da vida, em casa fiz a mesma coisa no VMware Workstation 6 do Linux, e não funcionou…
Sem nenhuma mensagem de erro anormal no dmesg e no /var/log/messages, resolvi agir sozinho e tentar resolver o problema. Testei de tudo, até que… Removi o kernel Xen e instalei o kernel “comum”. Não sei por que, mas sei que funcionou, e a rede já subiu automaticamente após o reboot!
Tem lógica? ¬¬
(comentário infame: Se fosse Windows…)
Artigos do Timm. 
