A controvérsia quanto à nomenclatura GNU/Linux é uma disputa entre membros da comunidade de software livre e código aberto. É centrada em torno da denominação do núcleo de sistema chamado "Linux", e a vontade de utilizar esta nomenclatura como um termo genérico para tudo relacionado ao mesmo. O termo defendido pela Free Software Foundation (FSF), para relacionar o núcleo do sistema com as ferramentas desenvolvidas pela fundação GNU seria GNU/Linux, ficando o nome "Linux" para ser utilizado apenas quando se referindo ao núcleo Linux. O nome é por vezes pronunciado como "GNU com Linux".
https://pt.wikipedia.org/wiki/Controv%C3%A9rsia_quanto_%C3%A0_nomenclatura_GNU/Linux
Eu peguei esse trecho da wikipedia. Abrindo um pequeno comentário sobre o mesmo: a versão em português está bem diferente da versão em inglês e fica ao critério do leitor dar uma olhada em ambos e decidir qual está melhor. Voltando ao assunto, a guerra entre os termo Linux e GNU/Linux. A briga vem de longa data, basicamente quando Linux começou a crescer exponencialmente em popularidade e deixou o projeto GNU em sua sombra. O bom doutor, Richard Stallman, ficou famoso por suas longas interjeições sobre o assunto. E virou meme. Infinitos memes.
O sistema operacional era GNU no início, mas por conta do kernel na época não estar pronto, usaram Linux. Mas não imaginavam que a força de comunidade ao redor do Linux seria tão grande e tão marcante. Ao ponto do Linux ter sido somente um kernel no início, mas hoje ser uma fundação e com vários projetos abrigados, como o OpenTofu, Linux para setor automobilístico, CNCF (Cloud Native Computing Foundation), etc. Por simplicidade, muita gente chama o sistema operacional inteiro com Linux somente. E isso, claro, ganhou força por ser mais fácil e simples que dizer GNU/Linux ou GNU+Linux.
Dentro dessa discussão existe ainda o ponto que alguns levantam que dentro de um sistema operacional, geralmente aquilo que você usa de uma distro - distribuição de Linux, não depende só do GNU. Existem outros códigos, projetos e licenças ali. De MIT a Apache, de KDE a Gnome, e assim por diante. Então se fosse pra dar crédito a todos ali, deveria ser chamado MIT/Xorg/Apache/Git/GNU/Linux ou qualquer outra coisa tão bizarra ou até mais que isso.
Claro que grande parte das coisas ali não existiriam sem a contribuição do projeto GNU, principalmente com o GCC. Até mesmo os BSDs dependeram do GCC até a Apple botar dinheiro no llvm/clang - e por conta disso estavam todos parados no GCC 3.2 por causa da mudança pra licença GPLv3, então a Apple ajudou muito.
E existe ainda a discussão, bastante rasa, de alguns de que Linux não roda sem GNU. Isso já foi demonstrado tanto pelo Android que não é verdade. E agora existem tanto o Chimera Linux, sem absolutamente nada de GNU e usando algumas ferramentas escritas em rust, quanto o Alpine Linux, feito pra containers.
Mas o ponto que eu queria abordar aqui, pois essa discussão já existe faz décadas e nada mudou muito, foi um artigo que peguei no site do GNU. Eu particularmente achei maravilhoso.
https://www.gnu.org/distros/common-distros.en.html
tl;dr: basicamente o que está escrito é que o projeto GNU não endossa as distribuições porque pra isso não pode distribuir nada que não seja software livre. Então quem usa firmwares binários, os blobs, não é endossado como GNU. Nem quem permite instalação de software proprietário. Sim, quem permite. Pois o OpenBSD não carrega firmwares binários por questões de segurança. Nem contém softwares proprietários no sistema operacional. Mas o sistema de ports, que são scripts e Makefiles de contribuidores e de usuários, esse instala softwares não livres. E isso é o suficiente pra GNU não endossar como... um sistema GNU??? Apesar da hipocrisia, acho que não seria o caso de nomear o OpenBSD como GNU de qualquer forma.
Mas o interessante é que ela acaba com a discussão. Se contém firmware ou é possível instalar software proprietários (steam, google chrome, etc) então não é GNU. Muito bem. Então nem é mais preciso a discussão sobre o nome. O nome é Linux e pronto :)
Interessante que referem-se às distros como GNU/Linux, como no caso do Arch GNU/Linux, enquanto o próprio Arch está como Arch Linux.
Pra terminar, deixo aqui vocês com os melhores memes desse tema.
Resolvi dar aquele tapa de fim de ano no raspberry pi que tenho, versão 3 e talvez B mas não tenho certeza. E fiz upgrade pro Bookworm, último release do Debian.
O site não recomenda fazer isso e sim reinstalar o sistema operacional. Mas eu sempre tento o upgrade primeiro e guardo a opção de reinstalar pro último caso.
Acabei perdendo acesso ao wifi durante o upgrade e precisei tirar ele da janela e mexer aqui na mesa. Nada demais e aparentemente deu certo.
Aparentemente...
Toda vez que eu tentava algum comando que mandasse muitos dados como "dmesg" ou "journalctl -b -1", a conexão travava. E como fica ali na janela, sem cabo de rede perto, eu nunca soube se era problema do ssh ou do wifi ou que simplesmente travava. Apenas sabia que depois que travava eu não conseguia mais conectar.
Junto a isso as fotos da janela começaram a sair muito ruins. Com muita exposição.
No fim acabei botando de novo aqui na mesa e mexendo pra ver se acertava a parte do ssh.
Achei uma dica em "https://discourse.osmc.tv/t/solved-ssh-connection-sometimes-hangs/76504" pra alterar o "/etc/ssh/sshd_config" e adicionar as seguintes linhas:
IPQoS cs0 cs0
E reiniciando o sshd. Realmente deu certo. A conexão passou a ficar estável. O segredo foi mudar o ToS pra best effort com cs0.
Eu também mudei o /etc/rc.local pra rodar e deixar o wifi sem power management e evitar qualquer problema de conexão que esse pudesse causar.
iwconfig wlan0 power off
A parte da câmera eu não consegui acertar aqui na mesa. Simplesmente não consegui abrir o programa gráfico pra isso. No fim fiz ajustes no programa que uso com rpicam-still, que parece ser o novo programa pra usar.
Eu ainda não olhei como ficou a exposição da manhã, mas a de noite está bacana.
E no fim arrumei com o parâmetro "--shutter".
Quem quiser olhar ou re-usar o script, está aqui no github:
Eu já tinha descrito como usar aceleração de hardware pra juntar imagens jpeg e criar um vídeo em usando a GPU para renderizar vídeo. Mas o texto todo abordou apenas os testes que fiz no laptop que tinha na época, com GPU integrada Intel.
E como fazer o mesmo com NVIDIA?
Aqui está a receita de bolo direta:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -r 1 -i G%04d.JPG -c:v h264_nvenc -b:v 5M -pix_fmt cuda output.mp4
Simples assim ele gera uma grande image output.mp4, que depois eu uso no kdenlive.
Claro que não é assim tão simples. É preciso ter os arquivos da GoPro gerados no padrão G0000.JPG, G0001.JPG, etc.
O que faço então é copiar todos os arquivos que vou precisar dentro do mesmo diretório (uso Gwenview pra isso). E depois eu rodo o seguinte script:
#! /usr/bin/env bash counter=0 for img in G*.JPG do serial=$(printf "%04d" $counter) new_name="G${serial}.JPG" echo "$img => $new_name" mv $img $new_name counter=$((counter++)) done ffmpeg -hwaccel cuda -hwaccel_output_format cuda -r 1 -i G%04d.JPG -c:v h264_nvenc -b:v 5M -pix_fmt cuda output.mp4
E pronto. Imagem gerada em output.mp4 pra ser usada no kdenlive.
Como eu não consegui fazer o kdenlive funcionar bem com a placa NVIDIA, é mais rápido fazer essa primeira geração assim via ffmpeg mesmo.
O script está disponível no GitHub:
https://github.com/helioloureiro/homemadescripts/blob/master/render-video-from-gopro-photos.sh
Por algum motivo bizarro meu mouse passou a não funcionar quando ligo meu PC. A propósito, para fazer minha parte quanto à crise energética na europa, eu passei a deixar meu PC desligado. Só o ligo quando vou usar, e depois desligo novamente. Algo que não fazia há algumas décadas.
Mas voltando ao assunto mouse, por algum motivo bizarro o mouse parou de funcionar. Ao desconectar e reconectar na USB, ele passava a funcionar.
Então resolvi fazer isso por software, num script que botei no /etc/rc.local
, uma vez que rodo o rc-local
no systemd
.
MOUSE_PRODUCT="G203 Prodigy Gaming Mouse" cd /sys/bus/usb/devices || \ die "It seems /sys interface isn't available." echo "Detecting mouse:" mouse_id="" for d in * do if [ ! -f "$d/product" ]; then continue fi echo -n " * $d: " product=$(cat $d/product) if [ "$product" = "$MOUSE_PRODUCT" ]; then echo "$product (DEVICE FOUND)" mouse_id="$d" else echo $product fi done if [ -z "$mouse_id" ]; then die "device not foud" fi echo "Restarting $mouse_id ($MOUSE_PRODUCT)" echo " * unbinding" echo "$mouse_id" > /sys/bus/usb/drivers/usb/unbind sleep 3 echo " * binding" echo "$mouse_id" > /sys/bus/usb/drivers/usb/bind
Esse foi o código inicial que usei, mas descobri logo que dar um reset no mouse não era o suficiente. O mais efetivo era dar um reset no hub USB em que está conectado. Assim alterei pra usar "USB2.0 Hub".
O resultado:
helio@goosfraba ~> sudo homemadescripts/restart_mouse.sh Detecting mouse: * 1-4: CSR8510 A10 * 2-5: Lexmark MC3224dwe * 5-1: PLAYSTATION(R)3Conteroller * 8-1: USB2.0 Hub * 8-1.1: HyperX Quadcast * 8-1.2: HD Pro Webcam C920 * 8-1.3: G432 Gaming Headset * 8-1.4: USB2.0 Hub * 8-1.4.1: Keychron C1 * 8-1.4.4: G203 Prodigy Gaming Mouse (DEVICE FOUND) * 9-1: USB3.0 Hub * 9-1.4: USB3.0 Hub * usb1: OHCI PCI host controller * usb2: EHCI Host Controller * usb3: EHCI Host Controller * usb4: EHCI Host Controller * usb5: OHCI PCI host controller * usb6: OHCI PCI host controller * usb7: OHCI PCI host controller * usb8: xHCI Host Controller * usb9: xHCI Host Controller Restarting 8-1.4 (USB2.0 Hub) * unbinding * binding
e temos um mouse funcionando :)
O código está no github: https://github.com/helioloureiro/homemadescripts/blob/master/restart_mouse.sh
Logo que passei a usar o archlinux, que descrevi em A era do Arch Linux, descobri rapidamente que existe um repositório chamado AUR, ArchLinux User Repository.
O AUR é basicamente um respositório de repositórios com código fonte pra criar pacotes pro archlinux criado pros usuários. Não é preciso criar muito vínculo com o projeto e basta puxar seu pacote lá.
Em um desses dias, durante um upgrade com pacman, apareceu pra mim que um pacote python estava desatualizado, marcado como órfão. Então decidi arregaçar as mangas pra enviar um patch de atualização pro pacote.
Li a documentação de como gerar os pacotes no archlinux, que é muito, mas muito, muito fácil. O sistema é fácil pra descomplicar a vida. É praticamente um Makefile que você configura e bota pra rodar. E tudo é controlado com git.
Então meio que adotei o pacote e o tenho mantido atualizado desde então: https://aur.archlinux.org/packages/python-pytelegrambotapi
A desburocracia é imensa. Foi só clonar o repositório, alterar, testar e mandar um push com o update.
O lado ruim da coisa é que qualquer coisa pode ser enviada pra um desses repositórios. Não há verificação. Na verdade parte da ideia do AUR é essa mesmo: pouca burocracia, mas você é responsável pelo que usa. Então é por sua conta e risco pegar pacotes de lá e assume-se que deu uma boa olhada no PKGBUILD, que é a instrução de como o pacote é gerado. Pra esse pacote do pytelegrambotapi por exemplo o arquivo é esse aqui: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-pytelegrambotapi
Só de olhar esse arquivo dá pra perceber o porquê adotei o pacote AUR: é muito fácil manter. Muito.
Mais um ponto positivo pro archlinux.
E você? Ainda não migrou pra ele?