Um pai desafiou os dois filhos a contornarem o protetor de tela do Linux Mint e eles conseguiram ativando o teclado virtual e digitando - com o teclado real e virtual ao mesmo tempo - rápido o suficiente para provocar um problema na biblioteca que gera o teclado virtual na tela, levando o protetor de tela junto.
O bug foi corrigido há 3 dias no Mint e no Void e foi reportado ontem ao Arch.
O autor do XScreenSaver (provavelmente um dos mais antigos protetores de tela para Linux e afins) voltou a fazer duras críticas depois da falha e relembrou que o GNOME violou a licença do programa dele tempos atrás, o que significa que os forks do GNOME também estão em violação.
Jawinski já tinha acusado os desenvolvedores dias atrás no Twitter. Na ocasião, ele havia se referido ao “gnome-screensaver” como um “lixo inseguro”.
Na verdade bug são descoberto na tentativa e erro.
Você só testa e nunca sabe de onde vai aparecer.
O que faz com que as chances de uma criança encontrar um bug seja a mesma de um adulto o que diferencia é a quantidade de teste feita que aumenta a chance.
Tipo não precisa saber logica só precisa testar.
É por isso que eu não procuro bug eu não tenho paciência de ficar testando infinitamente um software.
Mais tem pessoas em que isso é um passatempo.
Mas, encontrar e ainda assim “reportar” mesmo que acidentalmente a um adulto e esse adulto ainda por cima ter conhecimento de que se trata de um bug e levar isso adiante convenhamos que é algo muito específico se pensarmos em termos de probabilidade. Não é toda hora que algo do tipo acontece.
Você leu?
O pai pediu para eles desbloquear a tela foi ai que eles acho o bug.
Provavelmente o pai viu pergunto como eles fez e testo novamente e reporto.
Não necessariamente foi a criança que reporto tem que ler o contexto.
Fiquei curioso para ver como o KDE fez o bloqueio de tela e pelo visto a implementação deles é um pouco mais robusta:
O protetor de tela é composto de duas janelas, o ksmserver (mais simples, gera uma tela preta) e o kscreenlocker_greet (mais complexo e propenso a bugs, que pergunta senha). Se o segundo travar, é reiniciado pelo primeiro (que mantém a tela preta); se o primeiro travar, o KDE todinho cai.
Para mudar do QT para outro recurso teria que refazer os códigos quase do zero?
Ou tem algum recurso que usa muitas linhas iguais?
E para usar o KDE eu teria que pagar licença para a QT Company ou só paga que desenvolve?
Basicamente. Muita coisa precisaria ser modificada. E o Qt é um mundo à parte, ou seja, escrever em C++ usando o Qt vai produzindo uma relação de dependência que não é fácil de quebrar. É como portar um software, vai demandar muito esforço.
Não precisa pagar para usar o KDE, ele é distribuído livremente, assim como o Qt. A questão da empresa é sobre releases LTS com suporte comercial, mas de qualquer forma, o Qt tem duplo-licenciamento e algumas partes dele são completamente GPL. O KDE tem um acordo que garante que a dependência não pode ser quebrada, se a detentora quiser fechar o código, o KDE pode fazer um fork.
Nem sempre, o que aconteceu aqui foi meio que um ‘teste de caixa preta’, existem técnicas como teste de unidade e teste de integração que não envolvem tentativa e erro mas sim testes bem definidos onde você sabe muito bem o comportamento esperado.
A maioria usam estes métodos que falei, honestamente não só as distros, diversos softwares usam UT e IT, é algo meio comum em CI/CD. Mas claro existem outras formas de teste bem definidos, outros níveis que podem ser automatizados, até mesmo em alguma medida testes de aceitação do usuário podem ter sua gestão automatizada, um caso particular é a SUSE e o Fedora com openQA com uma abordagem mais direcionada a distribuições e programas como um todo.