Boot Time!
Mesmo depois de ver inúmeras discussões onde se tentam arranjar n formas de reduzir o tempo de boot do Linux, ainda não consigo entender onde está a real necessidade de o fazer...
É claro que há um tempo máximo de boot que se deve evitar ultrapassar, mas para além disso o que realmente interessa é ter um sistema rápido e leve imediatamente após o login e não cortar uns míseros 30 segundos a algo que se faz apenas uma vez ao dia (e não estamos a falar de sistemas embebidos).
Existem muitas soluções para este "problema", que passam normalmente por paralelizar o arranque dos serviços - para que uns consumam CPU enquanto outros esperam por I/O - e/ou permitir o login mais cedo, enquanto alguns serviços ficam a arrancar em background.
A primeira solução seria perfeitamente aceitável se não acabasse por trazer uma série de novos problemas que, a meu ver, podem tornar-se bastante mais graves.
Gerir as dependências entre serviços seria mais ou menos trivial se estas fossem fornecidas directamente pelos autores originais do sofware. No entanto, tal é muito difícil de ocorrer no mundo real devido às diferenças entre as distribuições, que muitas vezes obrigam à existência de scripts "start/stop" completamente diferentes. Isto implica que terão de ser as distribuições a criar as dependências, o que por sua vez implica (em alguns casos) que as coisas poderão não funcionar a 100% por falta de um conhecimento profundo acerca dos serviços envolvidos (o arranque paralelo pode revelar problemas que não ocorrem com um arranque sequencial, p.ex. o caso das placas de rede que mudam de ordem a cada boot no SUSE - algo que me deu grandes dores de cabeça para contornar).
Quanto a arrancar serviços em background após o login... bem, esta é a solução que mais me incomoda.
Se por um lado se quer dar uma ilusão de velocidade permitindo o login mais cedo, por outro dá-se uma sensação de extrema lentidão nos minutos seguintes...
Por mais potente que seja a máquina, ao arrancar o Windows (onde este método é usado) eu fico sempre com uma sensação:
Seria melhor se a malta das distribuições se preocupasse com outras coisas mais importantes, em vez de consumirem quantidades industriais de tempo nestas demandas estéreis.
É claro que há um tempo máximo de boot que se deve evitar ultrapassar, mas para além disso o que realmente interessa é ter um sistema rápido e leve imediatamente após o login e não cortar uns míseros 30 segundos a algo que se faz apenas uma vez ao dia (e não estamos a falar de sistemas embebidos).
Existem muitas soluções para este "problema", que passam normalmente por paralelizar o arranque dos serviços - para que uns consumam CPU enquanto outros esperam por I/O - e/ou permitir o login mais cedo, enquanto alguns serviços ficam a arrancar em background.
A primeira solução seria perfeitamente aceitável se não acabasse por trazer uma série de novos problemas que, a meu ver, podem tornar-se bastante mais graves.
Gerir as dependências entre serviços seria mais ou menos trivial se estas fossem fornecidas directamente pelos autores originais do sofware. No entanto, tal é muito difícil de ocorrer no mundo real devido às diferenças entre as distribuições, que muitas vezes obrigam à existência de scripts "start/stop" completamente diferentes. Isto implica que terão de ser as distribuições a criar as dependências, o que por sua vez implica (em alguns casos) que as coisas poderão não funcionar a 100% por falta de um conhecimento profundo acerca dos serviços envolvidos (o arranque paralelo pode revelar problemas que não ocorrem com um arranque sequencial, p.ex. o caso das placas de rede que mudam de ordem a cada boot no SUSE - algo que me deu grandes dores de cabeça para contornar).
Quanto a arrancar serviços em background após o login... bem, esta é a solução que mais me incomoda.
Se por um lado se quer dar uma ilusão de velocidade permitindo o login mais cedo, por outro dá-se uma sensação de extrema lentidão nos minutos seguintes...
Por mais potente que seja a máquina, ao arrancar o Windows (onde este método é usado) eu fico sempre com uma sensação:
Uau, o Windows arranca rápido... mas esta máquina é mesmo lenta! Vou mas é tomar um café enquanto isto faz não sei o quê...
Seria melhor se a malta das distribuições se preocupasse com outras coisas mais importantes, em vez de consumirem quantidades industriais de tempo nestas demandas estéreis.
Carlos Rodrigues - 10.5.05 |
permalink
Caro Carlos,
Sem querer ser ofensivo, julgo estares a ser um pouco "quadrado" na tua análise. Vou-te dar o meu exemplo e facilmente constatarás que a questão do boot time não é assim tão desprezível ou sequer irrelevante:
Possuo um portátil Asus S5200N (SuSE 9.3) cujo suspend-to-ram não funciona. O Suspend-to-disk por vezes corrompe o filesystem. Logo, a minha única alternativa é ligar e desligar com muita frequência.
Acredita que é uma verdadeira maçada aguardar pelo infinito tempo de boot. Isto tem _mesmo_ de ser melhorado, para que o Linux no desktop vingue.
Por
Mário Lopes, em 10 Maio, 2005 13:59
Desse ponto de vista sim, tens toda a razão. No entanto, apenas a questão da paralelização ganha uma justificação forte, porque a questão do early login continua com poucas vantagens e com os mesmos problemas.
Mas... mesmo assim eu acho que a paralelização vai criar mais problemas do que os que irá resolver.
Repara que eu não sou contra isto, apenas acho que enquanto não existir uma forma 100% transversal a todas as distribuições (e passível de ser implementada directamente upstream), não passará de um hack (em cima de uma data de hacks).
Por
Carlos Rodrigues, em 10 Maio, 2005 16:39
carlos,
o early login também pode ter as suas vantagens. Imagina que tens de ligar não uma, mas vinte máquinas em simultâneo (tipo sala de formação).... ligas o botão e (quase) de imediato colocas o login, e passas para outra.... O tempo de espera depois, já é o tempo em que o formando está a entrar na sala e a sentar-se....
Por
cparis, em 10 Maio, 2005 17:14
Ou então ligas todas em sequência, e depois voltas à primeira e fazes todos os logins também em sequência. ;)
Por
Carlos Rodrigues, em 10 Maio, 2005 19:28