Descreve-se a otimização do Slackware para uso em desktops. Sendo um excelente sistema, sua fama de difícil entretanto tem afastado muitos usuários menos experientes. Na verdade o termo mais adequado seria "configurável". Ele serve tanto ao usuário mais simplista quanto ao provedor de internet ou emissora de rádio comercial.
Para uso doméstico restrito a uma ou duas pessoas responsáveis, as senhas
mais atrapalham do que ajudam. A cada vez que seja necessário usar o root
digita-se su e ele responde password.
Se já colocou senha, ela e esse pedido podem ser eliminados através do
arquivo /etc/shadow. Da primeira linha elimine um grupo de letras e sinais
desconexos, senha encriptada:
root:EnCl6vi6y2KjU:9804:0:::::
Para que fique parecida com esta abaixo:
root::9804:0:::::
O mesmo para usuário comum.
Interessante esse /etc/shadow. Se for aberto como usuário comum ele aparece como página em branco.
# bash /etc/rc.d/rc.messagebus restart
Para implementar a mudança.
Configurar KDE
Kuser
Coloque seu usuário nos grupos disk, plugdev, cdrom, floppy, haldaemon,
power, video, wheel. Com isso ele pode fazer um bocado de coisas, sem alterar o
sistema.
Control center
Elimine tudo que for transparência, animação etc. No que respeita aos
ícones, fontes, figuras de fundo, barras etc., quanto maiores mais RAM de vídeo
requerem.
A diminuição do uso de recursos é voltada para um micro modesto, se tem
um novinho obviamente pode se dar a luxos e belezas maiores.
Appearance & themes
Background. O mais simples é cor única. Opções avançadas, diminua a memória
reservada ao cache em background (se tiver pouca), mude a cor das letras no
desktop etc.
Fonts. Configure anti-aliasing para full, vale a pena.
Launch feedback. No busy cursor; Startup notification a 2 segundos.
Screen saver. Não uso.
Splash screen. Nenhum.
Desktop
Multiples. Inicialmente deixe dois, depois, se vir que não usa, diminua. Sempre terá o ctrl alt F6 para resolver pepinos.
KDE components
Performance. Minimize o uso da memória sempre.
Service manager. Desabilite todos.
Session manager. Inicie com uma seção vazia para não correr o risco de ficar carregando ad eternum um monte de processos usados tempos atrás.
Peripherals
Display. Se não fez no rc.S, coloque os tempos para desligamento do monitor após desuso.
Mouse. Aumentar a aceleração para 4 melhora seu desempenho, mas aumenta o consumo da RAM de vídeo, podendo causar instabilidade. É para quem tem sobrando. 3 é um valor bonzinho.
Regional
Keyboard shortcuts. Coloque as teclas de atalho tradicionais para reboot (ctrl alt del) e desligamento do sistema (ctrl alt end), bem como outras que desejar.
Sound
Retire os sons de aviso e notificação. Habilite o sistema de som para ALSA e Full duplex.
System administration
Login manager. Use modo administrador. Background em cor única, sem quadro. Conveniência para auto-login do seu usuário, para o sistema já entrar no KDE direto.
Há outras opções.
Sistema de hotpluging
Usuários do Slack 12 não precisam preocupar-se com isso. O sistema
Udev-Hal funciona bem.
Para versões anteriores as configurações para USB pelo Udev (kernel 2.6) e
Hotplug (kernel 2.4) estão descritas em dois outros artigos (ZOBY 2007).
O Autofs promete montar e desmontar automaticamente qualquer dispositivo
fixo ou removível, inclusive liberando o CD-Rom para ser ejetado a qualquer
momento em que não esteja sendo acessado. Entretanto é extremamente
instável, chegando a travar o Konqueror ou todo o sistema ao acessar pendrives
Mp3, limitando seu uso a CD-Rom e disquete. Vem escrito para Debian e Red Hat
(mesmo no CD do Slack!), mas há correções na internet (Dennis Bijwaard in
RIBEIRO 2004; autofs-3.1.7-i386-zoby.tgz).
Lendo os arquivos disponíveis nas pastas /etc/hotplug e /etc/udev dá para
desconfiar que esses dois sistemas, *se plenamente configurados*, são capazes
de realizar todas as tarefas de montagem e desmontagem de dispositivos
removíveis. O problema é que essa configuração não vem pronta. E os que sabem
fazê-lo não parecem dispostos a divulgar um passo-a-passo.
Se compilar o kernel, coloque para carregar módulos automaticamente sob
demanda, e os módulos mais usados (usb storage, modem etc.) faça-os built in.
Particularmente prefiro colocar o máximo built in, mesmo isso aumentando o
tamanho do kernel. Mas essa escolha é meio cega.
CidoLoco (2007), com Slackware 11, plugou todos os seus dispositivos,
comandou lsmod para saber quais os módulos usados e dependências, colocou
ordem de carregamento para eles no rc.modules, desabilitou o rc.hotplug e
melhorou muito o tempo de boot. Entretanto, assim rc.hotplug não pode ser usado
para montar automaticamente dispositivos USB e semi-automaticamente o CD-R.
Configura a tendência do kernel >= 2.6.6 a usar swap. Para saber o valor do
seu:
$ cat /proc/sys/vm/swappiness
O default é 60. Um número mais baixo melhoraria o desempenho se tiver muita
RAM (1 Gb):
$ su -c 'sysctl -w vm.swappiness=10'
A linha seguinte poderia ser acrescentada ao /etc/rc.local:
sysctl -w vm.swappiness=10
Ou editar /etc/sysctl.conf (se tiver esse arquivo)
acrescentando:
vm.swappiness = XX
XX deve ser um número de 0 a 100.
Valor maior faz aumentar a alocação para swap, valor menor manterá o
máximo na RAM. Se tiver muita RAM (1 Gb e mais), valor menor é melhor e vice
versa. Quanto mais RAM livre, mais está disponível para aplicativos.
Mesmo entre desenvolvedores de kernel essa questão suscita polêmica.
Havendo quem mantenha o valor 100 em seu desktop com 512 Mb RAM.
Gustavo PICOLOTO (2004), usando Fedora Core 2, encontrou 80 como o
melhor valor em um notebook Toshiba com 196 Mb de RAM, tendo Mozilla,
OpenOffice, Gaim e Gnome em execução. Diz que devem ser feitos testes em
cada micro, com mudanças de 10 ou 20 por vez.
Os valores 10 e 30 congelaram meu vídeo após algumas janelas e voltei ao
default. Talvez isso tenha ocorrido porque tenho "pouca" RAM (para quem teve um
386 SX muito eficiente com 4 Mb, é chocante dizer que 256 é pouco).
Para Windows 95/98 há um programinha chamado Maxmem (Analog X) que
permite decidir que porcentagem da RAM permanecerá livre. Usei por vários anos
e senti grande melhora ao manter mais RAM livre, na época tinha menos de 128
Mb. Provavelmente o que o programa fazia era alocar mais dados para o swap,
swappiness maior.
Compilação
Recompilar o kernel de acordo a seu hardware não é difícil e notavelmente
melhora o desempenho geral do micro. Há diversos tutoriais na Internet, uns bons
e outros ruins. O erro que não pode ser cometido é colocar o sistema de arquivos
do disco raiz como módulo, ele tem de ser built in. Esse é a mais freqüente causa
de kernel panic. Outro erro é simplesmente recompilar com a mesma
configuração, nada mudará.
Se trocar a versão do kernel, será preciso instalar o alsa-driver substituindo
a pasta /lib/modules/versão-do-kernel pelo número da sua nova versão,
recompilar, reinstalar.
Nos dois últimos CDs do Slack estão os códigos-fonte de todos os pacotes. Se
forem compilados especificamente para seu processador o desempenho deve
aumentar muitíssimo. Mas que trabalho! Se as atualizações não fossem tão
freqüentes valeria a pena.
Extras
O Prelink 1.0 otimiza a ligação entre os binários e bibliotecas, assim
diminuindo o tempo de abertura dos programas. Há posts em fóruns relatando
melhorias esplendorosas, e outros com piora do desempenho. Em meu sistema a
melhora foi compatível com o descrito na documentação do software, cerca de
30%. O que estiver muito além disso deve-se à empolgação do usuário, e as
pioras a erros de uso.
O tgz prelink-20060213-i686-1jto em
http://www.linuxpackages.net/pkg_details.php?id=9132 não posiciona o .conf
corretamente, deixando-o na pasta de docs junto com vários outros arquivos
desnecessários. Copie /usr/doc/prelink.../prelink.conf para /etc.
Comande:
# prelink –amR
E espere, não interrompa-o antes do fim. Para desfazer:
# prelink –au
Criei um pacote corrigido: prelink-1.0-i686-1.tgz. Para não iniciar o kdeinit
desnecessariamente e melhorar mais a performance acrescente a /etc/profile:
[1] Comentário enviado por fulllinux em 14/02/2008 - 13:28h
Blá, legal!!!
Mas ká para nós... praticidade já é uma qualidade do Slackware, se um usuário desktop for lembrar de tudo isso em uma pós instalação ele vai pirar de prima!
Isso otimiza inicialização e finalização de um sistema, mas não altera a agilidade de um sistema durante o running, pois ele continua com o mesmo desempenho durante a sua utilização!
[3] Comentário enviado por removido em 14/02/2008 - 17:06h
O artigo está bom, mas gostaria de fazer pequenos comentários.
As frases:
"Não coloque senha para root, isso evitará que o sistema peça para digitá-la cada vez que você quiser fazer algo com o usuário todo poderoso."
e
"É o fato de trabalhar e navegar com usuário comum que torna o Linux imune a vírus e mais estável."
são contraditórias.
E acho que a instalação pode ser simplicaficada da seguinte maneira: instala o slack full, e depois nos arquivos rc.M e rc.inet2 basta comentar os serviços que não serão utilizados. Se vierem a ser utilizados, basta descomentar a linha referente ao mesmo.
[7] Comentário enviado por zoby em 15/02/2008 - 06:54h
O renatobach tem alguma razão. Se não há senha p/ root, um programa q tente dar um su terá sucesso. C/o o artigo não era dirigido p/ alta segurança, esqueci esse furo.
Quanto a instalar o full, depende do espaço. A intenção era obter o melhor desempenho no menor hardware.
Fullinux: O desempenho é melhorado c/ a instalação de prelink (em Slack 12 não), compilação do kernel, autofs + Udev ou Hotplug e outros detalhes. Não dava p/ explicar tudo pq iria virar um livro.
[11] Comentário enviado por k33p em 03/05/2008 - 07:52h
Outro ótimo artigo, muito bem comentado!
Explicou diversos fatores do slack, do boot muito bom para quem precisar de alguma informação.
Claro que esse trabalho td pode ser agilizado e suplementado!
Poderia ter embalado já na recompilação do kernel tbm.
[12] Comentário enviado por zoby em 05/08/2008 - 01:08h
K33p, "embalado na compilação do kernel"!
Ensinar a compilar é fácil.
Descompacta em /usr/src/linux, cd /usr/src/linux
# make mrproper && make menuconfig
Salva e sai.
# mv -Rf /lib/modules/(uname -r) /lib/modules/(uname -r)OLD
# nice -n -20 make bzImage && nice -n -20 make modules && nice -n -20 make modules_install && cp System.map /boot/System.map && cp arch/i386/boot/bzImage /boot/vmlinuz && cp .config /boot/config && make clean
Compilou. O difícil para um artigo está lá no começo, o make menuconfig. Explicar, após entender:), cada uma das opções do kernel dá um livro.