O Linux pode danificar o hardware do computador? [fechadas]

Question

Vou instalar o Elementary OS no meu computador de mesa (i3 550, 4GB de RAM). Há algo que eu deva observar antes de ir para a instalação? Ouvi dizer que as distribuições do Linux não são tão compatíveis com o hardware do computador quanto os sistemas operacionais Windows, então haverá um problema?

    

Answer 1

Em teoria: qualquer software (incluindo o Windows) pode danificar o hardware: Sim.
Na prática: não.

O Linux não é diferente disso do que qualquer outro sistema operacional. A mesma (falta de) riscos como janelas, OSX, MacOS (clássico), FreeBSD, netBSD, OpenBSD, QNX, ...

not as compatible

Eu diria precisamente compatível. Nem menos nem mais.
Mas eu suspeito que você quer dizer "tem menos drivers ou obtém depois". Nesse caso, simplesmente não reconhecerá totalmente parte do hardware. Será feliz o trabalho. Você pode inicializar, editar arquivos, executar o Firefox, etc. etc. Mas verifique se existe um driver para qualquer hardware exótico.

Isso não é diferente do Windows. Especialmente ao atualizar com dispositivos mais antigos para os quais o fabricante não grava drivers atualizados.

    

Answer 2

Idealmente , não, o Linux (ou qualquer outro software) não deve ser capaz de danificar fisicamente o hardware. Não ter drivers pode significar que você não pode usar certas peças de hardware, mas também não deve ser capaz de danificá-los.

Infelizmente, houve casos em que hardware barato ou mal feito é fabricável por software. Por exemplo, um monte de firmware UEFI inicial não protegeu corretamente certas coisas, levando à capacidade de sobrescrever dados vitais e destruir sua placa-mãe [ 1 ] [ 2 ].

O Linux não prejudicará seu hardware mais do que qualquer outro SO , mas há certas coisas das quais ele não pode protegê-lo.

    

Answer 3

Apenas hardware defeituoso.

• Os escândalos acontecem. O brickgate de UEFI (mencionado por muskox) é um bom exemplo, mas raro.

• O hardware que reporta incorretamente seus recursos na verdade não é tão incomum. Por exemplo, os SSDs que afirmam oferecer suporte ao qued trim, mas não o fazem, e os controladores SATA que afirmam não suportam Gerenciamento de energia do link SATA , mas sim. As conseqüências são perda de dados e pior duração da bateria, respectivamente, mas não resultaram em danos físicos, AFAIK. Esses dispositivos acabam em listas negras e whitelists vergonhosas nos drivers, e o mundo continua, mas significa que um kernel muito antigo para o seu hardware é arriscado.

• Para alguns hardwares infelizes, os drivers ausentes significam falta de gerenciamento de energia. Para GPUs mais novas, isso significa que você ficará preso em uma configuração de baixo desempenho, o que é seguro. Mas se você estiver com alto desempenho e não houver refrigeração suficiente para essa quantidade de energia, e o componente não desligar sozinho quando ficar muito quente, ele ficará superaquecido. Isso seria uma falha de design, já que o mesmo poderia acontecer se o sistema operacional trava, o que também pode acontecer com o Windows. Ouvi falar de laptops ficando quentes porque as duas GPUs permanecem ativas, mas acho que elas se desligam antes que se torne perigosa.

Answer 4

tl; dr ... Sim, tecnicamente , mas não é culpa do sistema operacional.

Certos tipos de mídia de armazenamento (discos de estado sólido, SDCards, várias outras mídias baseadas em flash) têm um número limitado de ciclos de gravação que podem decorrer antes que ocorra a degradação física dos materiais do substrato de armazenamento.

Esse tipo de dano é geralmente mitigado por algoritmos de wear-leveling embutidos no próprio dispositivo de mídia. Mas uma vez que a podridão tenha começado, ela tende a acelerar, porque há menos e menos lugares para colocar os dados de nível de desgaste!

Você poderia facilmente escrever um script que forçosamente escreve vários terabytes de dados em um cartão SD barato e você descobriria que ele seria danificado severamente (se não fatalmente) até o final, o que levaria várias semanas (eu sei isso porque eu fiz isso:)).

Isto não é específico do sistema operacional, e assim, enquanto o Linux pode fazer isso, então <<> qualquer outro SO também.

    

Answer 5

Aqui a> é um artigo do SlashDot falando sobre como rm -rf --no-preserve-root / bloqueou placas-mãe UEFI devido à remoção de variáveis EFI:

For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.

Aqui é um post de um usuário no AskUbuntu detalhando sua experiência com rm -rf --no-preserve-root / usando sua placa-mãe:

However, upon restart, the monitor was not receiving any input at all. Also, the HDD indicator (or whatever the red light was) wasn't doing one thing. (It was off, in fact.) The fans were working and the DVD drive was, though. (I don't think that there is a PC speaker in there, so if you need some beep error codes, sorry.)

Com a resposta :

Point 1: Deleting /sys/firmware/efi/efivars/ should thrash your EFI configuration, but in a properly implemented EFI this should be recoverable.

Point 2: There is some pieces hardware out there with broken/poorly implemented EFI, which will can be permanently bricked by doing standard conform stuff to them. See for example the case where Ubuntu bricked some Samsung laptops by storing additional data in some EFI memory. This behaviour was fine by standard but broke this particular implementation.

Point 3: Running anything as root that writes to /dev/sda will destroy your partition table and/or filesystems. That's bad especially if you have no backup, but after partitioning, creating new filesystems and reinstalling your OS your machine will work again. So you can recover from it by booting some other media and redo your installation.

Point 4: Thrashing your EFI is a whole different kind of problem. In the worst case you won't be able to do anything with the machine as it will not get to POST. No booting from an other media, no entering some EFI utility to fix missing stuff. A that point your computer is a really expensive paperweight.

The problem occurs in distributions that run systemd and mount efivarfs writeable (at /sys/firmware/efi/efivars). Systemd needs to write there, so distributions using systemd are affected. However, there seems to be no indication that Upstart systems are affected.