É um termo muito amplo que, no contexto de software e tecnologia significa complicação, complexidade desnecessária ou crescimento extremo em termos de tamanho do source-code, número de dependências, redundância, recursos desnecessários, como por freep e uso de recursos, todos quais levam a uma tecnologia ineficiente e mal projetada com bugs: falhas, recursos inutilizáveis, vazamentos de memória e vulnerabilidades de segurança, além de obscuridade, feiúra, perda de liberdade e desperdício de esforço humano. Em palavras simples: bloat é a sobrecarga besteiras. Bloat é ruim e uma das maiores questões tecnológicas hoje. Criar bloat é uma engenharia ruim no seu pior e é o que está absolutamente assumindo toda a tecnologia moderna, principalmente devido ao capitalismo causando comercialização, consumismo, apressou produtos apenas trabalhos, criando demanda por hardware mais recente, permitindo também pessoas incompetentes, "vamos empurrar mais mulheres e minorias para a programação", tentando assumir empregos que não estão de forma alguma qualificados. Um termo relacionado, mas diferente, é bloatware, é usado entre normies e significa programas indesejáveis que consomem recursos de computador, geralmente sendo pré -instalados pelo fabricante de computadores. Preferimos focar no bloat.
SMR, suckless e outros grupos estão tentando abordar o problema e escrever software que seja bom, mínimo, confiável, eficiente e funcional. Nossos números são muito pequenos e, nesse empreendimento, estamos basicamente de pé contra o mundo inteiro e as empresas de tecnologia poderosas. A questão está não apenas no capitalismo empurrando bloat, mas também em pessoas comuns que não veem o problema, em parte devido à propaganda capitalista que promove o maximalismo, ninguém está apoiando as poucas pessoas que estão realmente tentando criar boas ferramentas, pelo contrário, essas pessoas Muitas vezes, enfrenta hostilidade do mainstream. A questão do bloat pode aparecer fora dos limites estritas da tecnologia de computadores, hoje em dia já podemos observar Science Bloat, a ciência está se tornando tão supercomplicada que 99% das pessoas não conseguem entender, elas precisam acreditar em "autoridades científicas". Sempre que um novo artigo será lançado, é provável que nem mesmo cientistas do mesmo campo, mas com uma especialização diferente o entenderão em profundidade e precisam simplesmente confiar em seus resultados. Isso combinado com a sociedade obcecada por interesse próprio dá origem à lavagem cerebral em larga escala e à propagação da propaganda aprovada pela ciência. Métricas tradicionalmente usadas para medir o inchaço incluem linhas de source-code, complexidade ciclomática, linguagem de programação usada, algumas linguagens são bloateds e inerentemente incapazes de produzir não bloat, também a escolha da linguagem indica prioridades e habilidades do desenvolvedor, número de dependências: pacotes, bibliotecas, hardware, tamanho binário ou tamanho do programa compilado, tempo de compilação, uso de recursos: RAM, CPU, uso de rede, desempenho: FPS, capacidade de resposta, anti-recursos: GUI, DRM, atualizações automáticas, formatos de arquivo como XML, portabilidade, número de implementações, tamanho da especificação, número de desenvolvedores e outros.
Foi observado que software fica mais lento mais rápido do que hardware fica mais rápido, o que agora é conhecido como lei de Wirth, isso decorre da lei de Moore, a velocidade do hardware dobra a cada 24 meses, sendo mais fraca do que a lei de Gate, a velocidade do software cai pela metade a cada 18 meses, ou em outras palavras: a estupidez dos desenvolvedores de software supera o brilhantismo dos gênios. Apesar disso, não há nenhuma medida completamente objetiva que diria "este software tem exatamente X% de bloat", bloat é algo julgado com base no que precisamos e queremos, quais compensações preferimos. A resposta para "quanto bloat" existe depende da resposta para "o que realmente é bloat?". Para responder a essa pergunta com mais precisão, não podemos nos limitar a simplificações como LOC ou número de dependências de pacotes, embora essas sejam estimativas boas para a maioria dos propósitos práticos, uma visão mais precisa é obtida perguntando cuidadosamente quais fardos e dificuldades de qualquer tipo vêm com uma determinada tecnologia, e também se e quanto de um mal necessário eles são. Perceba que se seu software não requer tecnicamente o pacote X para ser executado ou compilado, o pacote X pode ser de fato necessário para que seu software exista e funcione, um cliente de jogo multijogador puro não terá servidor como dependência, mas será inútil sem servidor, então de fato todo bloat presente no servidor agora é, em um sentido amplo, o fardo do cliente. Se encontrou um programa que é curto e não usa bibliotecas, você ainda tem que verificar se a linguagem em que ele foi escrito não é bloated, se o programa depende da execução em uma plataforma complexa que não pode ser implementada sem inchaço, se alguma peça de hardware altamente complexa, GPU ou 8 GB de RAM é necessária, ou se ela depende de algum serviço complexo de Internet. Você provavelmente pode julgar melhor a quantidade de bloat de forma mais objetiva perguntando o seguinte: se nossa tecnologia atual desaparecesse instantaneamente, quão difícil seria fazer essa peça de tecnologia funcionar novamente? Isso inevitavelmente levará você a investigar o quão difícil seria implementar todas as dependências.
Para uma rápida visão geral, vamos calcular a média de alguns dados ao longo do tempo, a tabela a seguir mostra o crescimento dos requisitos e tamanhos do sistema e faz a média deles para dar uma estimativa da taxa de inchaço com relação à primeira linha. Observe que alguns dados na tabela podem não ser completamente precisos, a interpolaçã e extrapolação foi usada para valores ausentes, estamos apenas fazendo uma estimativa, afinal, mas ainda observe que nosso uso de recursos de computação já cresceu quase 2000 vezes, apesar dos computadores serem geralmente mais lentos e menos responsivos da perspectiva do usuário:
TODO: tabela
A seguir está uma lista de softwares geralmente considerados um bom exemplo típico de inchaço. Tenha em mente que bloat é um termo relativo, o vim pode ser visto como um editor minimalista sem sucção quando comparado ao software convencional, IDEs, mas ao mesmo tempo é bloat quando comparado a programas suckless.
Alguns desses programas podem ser substituídos por bloat menores que basicamente fazem a mesma coisa, como Libreoffice com Ted, Godot com Irrlicht e Firefox com badwolf, no entanto, muitas vezes os resultados pomposos espetaculares que esses programas produzem simplesmente não podem ser reproduzidos essencialmente por nada mínimo, querer alcançar isso é realmente um erro de iniciante, o mesmo que querer alcançar a experiência Windows em um sistema GNU. Você nunca será capaz de fazer gráficos no estilo Unreal Engine com um motor de jogo minimalista, assim como você não será capaz de atirar na sua escola com poesia bem escrita, em ambos os casos, o primeiro é algo ruim que, no entanto, a maioria dos americanos quer fazer, o último é algo realmente bom que eles deveriam querer. Para se livrar do bloat, é preciso se tornar capaz de usar programas mínimos, isso significa desaprender a doutrinação de que "resultados maiores são melhores", é preciso entender que resultados mínimos em si são superiores e permitem uso de programas mínimos.
Além dos grandes programas típicos que até normies admitem que são bloateds, existe também bloat menor que muitas pessoas não veem como tal, mas que é considerado desnecessariamente complexo por alguns especialistas, idealistas e minimalistas hardcore, incluindo nós. O bloat pequeno é um assunto de piadas populares como "Ele usa fonte unicode! Bloat!". Essas são boas piadas, é legal tirar sarro do próprio idealismo. Mas isso não significa que bloat pequeno seja um conceito de piada, ele desempenha um papel importante no design de uma boa tecnologia. Quando identificamos algo como bloat pequeno, não precisamos necessariamente evitar e rejeitar completamente esse conceito, podemos apenas tentar torná-lo opcional. No contexto dos PCs de hoje, usar uma fonte Unicode não é realmente um problema de desempenho, consumo de memória ou qualquer outra coisa, mas devemos ter em mente que pode não ser assim em computadores muito mais fracos ou computadores pós-colapso, então devemos tentar projetar sistemas que não dependam de Unicode. Lembre-se que bibliotecas relativamente pequenas para coisas que são facilmente feitas sem uma biblioteca, como aritmética de ponto fixo, também são bloateds. Bloat médio e pequeno inclui:
O conceito de inchaço pode ser aplicado até mesmo fora do mundo da computação, por exemplo, para tecnologia não informática, arte, cultura e direito. Aqui, ele se torna sinônimo de besteira, mas usar a palavra bloat diz que estamos vendo o problema do ponto de vista de alguém familiarizado com inchaço informático:
Impulsionado por nada. Todo conteúdo é disponível sob CC0 1.0 domínio público. Envie comentários e correções para Mr. Unix em victor_hermian@disroot.org.