Degradação de CPU e HD na distribuição Linux de origem

1

Eu queria saber por muito tempo se as distribuições Linux baseadas em fontes, como o Gentoo ou o Funtoo, estão "destruindo" o sistema mais rápido que as binárias (como o Fedora ou o Debian). Eu estou falando sobre a degradação da CPU e do disco rígido.

É claro que, quando você está atualizando seu sistema, ele tem que compilar tudo a partir do código-fonte, então ele demora mais e seu processador é usado em condições difíceis (é mais quente e mais carregado).

Tais sistemas compilam centenas de pacotes semanalmente, então isso realmente importa? Esse sistema se degradará mais rapidamente que os baseados em binário?

    
por danilo2 26.09.2012 / 14:55

2 respostas

1

O hardware do computador não se degrada mais rápido quando está sendo usado, assumindo resfriamento adequado. Geralmente, o que mata a eletrônica é o calor, e o calor pode ser mitigado por resfriamento suficiente; em computadores pessoais modernos, isso normalmente significa resfriamento ativo por ar forçado, mas existem outras possibilidades (incluindo resfriamento a água e, em sistemas de baixa potência, resfriamento estritamente passivo / convectivo). Quais defeitos causam lentidão e queda de computadores antigos? e É possível que um roteador" fique ruim "com o tempo? toque nisso.

uma exceção principal para isso, e isso é armazenamento baseado em flash, como aquele usado em SSDs, que tem um número limitado de ciclos de gravação antes de cada célula flash se desgastar. No entanto, os SSDs modernos fazem grandes esforços para atenuar isso e, apesar do que as pessoas podem dizer que você selecionou para a carga de trabalho pretendida na maioria das cargas de trabalho de cliente e servidor são bastante duráveis o suficiente , ainda mais do ponto de vista do desgaste do flash. Isso inclui a compilação de software, que, embora tenha a tendência de criar um grande número de arquivos (envolvendo muitas gravações pequenas), também é altamente armazenável em cache pelo sistema e, portanto, não implica necessariamente tantas gravações em armazenamento estável. Como Serge destacou , como alternativa, você pode considerar a execução da compilação em um sistema de arquivos do tipo tmpfs, que normalmente usa RAM para armazenamento, mas recorrerá a trocar espaço se não houver RAM suficiente disponível. Isso também pode acelerar a compilação, uma vez que, particularmente para projetos grandes, a compilação tem mais probabilidade de ser restrita por IOPS do que a taxa de transferência de E / S ou CPU restrita; e mesmo se for restrito ao CPU, as IOPS mais altas alcançáveis através do uso de RAM para armazenar arquivos de código-fonte não irão piorar significativamente a situação.

O principal matador de eletrônicos, além do calor, são as impurezas de tensão, que são um fator da fonte de alimentação e, em grande parte, não estão relacionadas às tarefas que você executa no computador. Com uma fonte de alimentação devidamente classificada (que é principalmente uma preocupação se você mesmo construir um computador a partir de peças) e além de impurezas CA de entrada (o que afetará qualquer eletrônica), isso para todos os efeitos não será um problema.

    
por 16.10.2014 / 13:46
1

Se você realmente ajusta todos os pacotes desabilitando a funcionalidade desnecessária no tempo de compilação ou você tem algum clone específico do processador x86 que requer algumas otimizações específicas do compilador então seu sistema rodará ainda mais rápido que o mesmo sistema instalado a partir de uma distribuição binária . Quanto à degradação do disco rígido - você pode usar um volume separado para manter todos os seus arquivos intermediários de tais reconstruções que você acabou de formatar cada vez que a atualização foi concluída. A outra opção é executar toda essa construção em um dispositivo tmpfs que é realmente submetido a backup pelos arquivos / dispositivos de memória e troca, portanto, seu conteúdo é limpo de qualquer maneira em cada reinicialização do sistema.

    
por 26.09.2012 / 15:53