Uma coisa que afasta novos usuários do linux

Entendi totalmente seu ponto, mas mesmo n sendo nightly na minha visão ele n será mais estável que um debian ou ubuntu lts até porq salvo engano há upgrades de kernel e isso é algo q pode gerar incompatibilidades de hardware.

Também sou desenvolvedor e encontrar bugs nas aplicações rodando em diferentes sistemas e configurações é bem complicado. Sempre é preciso evidencias do ocorrido para poder conseguirmos tentar replicar.

Ai é que entra o ponto da discussão e o ponto que acho que muitos devs podem melhorar, um sistema de reportar bugs, ou ate mesmo logs gerados em uma determinada pasta que o usuário que queira reportar o bug, apenas mande o arquivo com uma descrição do problema. Mas o dev tem que implementar isto, o que nem todos fazem ou todas as aplicações possuem.

Isso poderia ser algo que com certeza iria melhorar o report de problemas, não precisando do usuário fazer malabarismos para conseguir informações e nem ele ficando frustrado com respostas como “Falta informações…”. E o desenvolvedor com certeza teria informações bem mais detalhadas já que foi ele que implementou o log de report.

Não é complicado fazer isso e nem leva muito tempo… mas nem todos pensam nesse tipo de coisa (talvez prioridades).

1 curtida

Telemetria basicamente, na qual muitos usuários Linux vão reclamar de ataque a privacidade. :thinking:

1 curtida

Depende dos dados que essa telemetria coleta.

Por que você usa Arch Linux então?

2 curtidas

Telemetria é uma coisa tão banal que deveria padrão nos software open source. O Baboo explicou uma vez como funciona e ajudar os desenvolvedores. Quando um crash acontece, se a telemetria estiver ativa, vai mandar um relatório técnico com dados técnicos de quando, como e em que circunstâncias o crash ocorreu, fica muito fácil para depurar e não depende do usuário que geralmente é leigo ficar reportando.

2 curtidas

O ponto que o nando3d levantou sobre ataque a privacidade é importante ser levantado pela comunidade. Telemetria é uma coisa que pode melhorar e muito a qualidade do suporte e ate da aplicação já que pode corrigir problemas mais rápido.

O ponto da privacidade sempre vai existir mas talvez para alguns ficarem mais tranquilos, essa telemetria ser feita (o log em si) internamente da aplicação sem pegar contexto ou coisas fora da aplicação. Diminui o numero de informações mas talvez não reclamem tanto de privacidade haha.

Isso é só uma ideia mesmo que poderia ser feito, sem que haja muitas reclamações.

2 curtidas

Sim, ele tem um video sobre isso no canal dele.

Esse tópico envolve uma série de questões e eu acho que a principal delas é não compreender como comunidades funcionam. No software livre/de código aberto, muita coisa é desenvolvida como um hobby ou por um pequeno grupo (em alguns casos, uma pessoa sozinha). E… não, esse grupo/indivíduo não tem obrigação de ser educado, prestativo, compreensivo ou profissional.

“Ah, mas isso afasta o usuário comum.”

Paciência. É assim que funciona. E não se aplica só para software livre/de código aberto direcionado a Linux. Vamos supor que o programa XPTO rode em Linux, Windows, macOS, BSD e o que mais permitir a compilação. Se o desenvolvedor tem a postura que você apresentou, ele não necessariamente vai “pegar leve” se o reclamante usar Windows. Tem projeto que nem se dá ao trabalho de fornecer binários pré-compilados.

A ideia de que é preciso “rezar” para o problema ser corrigido e, com rapidez, ainda por cima, é parte de uma construção equivocada de expectativas. Lamento, mas não é assim que funciona no software livre/de código aberto. E, lamento mais ainda, mas dependendo de como o projeto é mantido, nem com muita grana sendo doada, isso vai mudar.

Por outro lado, eu concordo que:

  1. Precisamos melhorar a manipulação/tratamento de erros;
  2. Precisamos melhorar a forma como bugs são registrados no downstream, para ter uma espécie de intermediário que consiga falar com o upstream (inclusive submetendo a correção, se possível);
  3. Poderíamos oferecer a instalação dos pacotes de depuração como parte dessa manipulação/tratamento de erros;
  4. Poderíamos ter uma interface mínima com o GDB para fornecer uma depuração automatizada.

Em geral, projetos com característica aglutinadora, como o KDE ou GNOME, meio que já fazem isso. Vide captura de tela do manipulador do KDE:

O problema é como conseguir monitorar programas de terceiros, sob uma variedade de condições. E, em tempo, o KDE também tem um guia sobre como reportar falhas.

Como sempre digo aqui, escolher bons projetos e boas distribuições é muito importante.

E, sobre voltar para o Windows, se software proprietário fosse garantia de qualidade em primeiro lugar, nem Linus, nem Stallman, entre outras figuras históricas, teriam precisado iniciar projetos como o Linux e o GNU, além disso, se fosse garantia de qualidade em primeiro lugar, eu não teria migrado para o Linux depois de sofrer com software proprietário durante toda a década de 1990 (e, mesmo depois de migrado, ainda segui sofrendo durante boa parte da década de 2000). Tenho certeza que muita gente migrou junto comigo, porque o ecossistema Linux só amadureceu desde então.

2 curtidas

Conseguir usar um computador por uma hora sem travar era um desafio nos anos 90.
Passar o dia sem um reboot era algo impensável.

Mesmo no Windows NT, muito mais robusto, já nos anos 2000, lembro de ser raro o dia que meu terminal de trabalho não precisava de pelo menos uma reiniciada. Como era muito lento, pedia desculpas aos clientes e ia para o meu café.

O linux foi criado por hobby (originalmente, tá no email inclusive) e o gnu por obsolescência programada (problemas com um driver sem suporte), o GNU é reacionário inclusive, já que foi uma resposta quase direta a carta aberta do Bill Gates que praticamente havia matado o software livre por hobby que era o padrão de distribuição na época, e o novo movimento do software Livre nem de longe resolveu o problema que o gerou, em muitos pontos intensificou, nem um dos dois é sinônimo de qualidade, porém é óbvio que um software comercial (não necessariamente livre ou proprietário) tende a ter maior qualidade por gerar ativos ao criador, um projeto por puro hobby em 100% dos casos é economicamente passivo, ou seja, gera perda de recursos, só ver os relatos de quem fez algo assim, não é sinônimo de má qualidade, porém no geral inferior a projetos comerciais seja no UX ou em funcionalidades

1 curtida

Eu já reportei muitos bugs para diferentes tipos de software, então tenho certa experiência.

O negócio é que para o bug report ser bom, ele tem que ser replicável com um mínimo de perfeição, tem que informar o sistema operacional usado (pode ser um problema que só ocorre no Linux ou numa distribuição específica), versão específica do programa (geralmente só se leva em consideração a última versão), hardware da máquina (o programa pode ter problema com placas de vídeo NVIDIA com driver proprietário e Intel HD Graphics, mas roda de boas com AMD e NVIDIA com driver aberto).

Por exemplo, uma vez tive problemas para rodar um arquivo de áudio no DeaDBeeF. Eu não podia simplesmente chegar para os caras e dizer que um arquivo de áudio não estava sendo aberto, eu tive que enviar o arquivo para que os desenvolvedores fizessem o diagnóstico. No outro dia, o problema foi corrigido.

Agora, com que tipo de programas você teve problemas para ter que baixar fontes e fazer depuração? Felizmente não precisei fazer nada disso.


Isso é o que me irrita, até com situações cotidianas. Quando eu estava usando o XFCE, precisei de um programa que bloqueasse o touchpad quando o mouse USB estivesse conectado. Quando fui pesquisar, encontrei respostas como “just write a script” ou até oferecia um script, mas não explicava onde e como aplicar aquilo. Felizmente consegui encontrar um programa, se bem que hoje uso o KDE Plasma que vem com essa opção “nativamente”.


Agora é o seguinte, distro de usuário comum é o *ubuntu LTS e derivados deste, ponto! De forma que deveria ser raro a ocorrência de problemas.

1 curtida

Sinceramente, eu até concordaria com você de forma incondicional, mas visto a postura do pessoal do KDE e da Mozilla, devo dizer que muita mudança e atitudes da comunidade de desenvolvimento open-source é movida pelo ego, onde os desenvolvedores fazem o que podem para forçar os usuários a usar seus softwares da forma como ELES querem.

No caso do KDE temos a implementação das medidas restritivas que impedem, normalmente, programas como dolphin, kate e kwrite como root. Os desenvolvedores gastaram esforço de desenvolvimento, recurso pessoal e tempo exclusivamente para IMPEDIR os usuários de usar os softwares deles da forma como ELES não querem.

No caso da Mozilla, temos a “incrível” funcionalidade de fechar o navegador com as teclas “ctrl+q”, hotkey normal de ser usada em aplicativos no linux e no Mac mas que atrapalha muito a usabilidade de muita gente, particularmente pelo fato de “ctrl+w” fechar abas individuais (um pequeno deslize na hora de usar essa tecla de atalho no linux e o navegador fecha sem aviso prévio). Para solucionar isso, outras empresas usualmente ou colocam opção de remapear as teclas de atalho ou colocam uma opção para desabilitar apenas o “ctrl+q”. Exemplo de empresa que colocou sistemas de segurança nisso é o google com o chrome.

No caso da Mozilla, existe solicitação para colocar uma opção de desabilitar essa tecla de atalhos a 21 anos (bugzilla-1), solicitação essa que se repete desde então com um grande número de requisições e gente tentando encontrar soluções como addons que são propositalmente desativados pela equipe da mozilla e posteriormente os tópicos de report de bug são fechados sem solução (addon-1, addon-2, bugzilla-2). Essa é uma reclamação extremamente comum, abertamente ignorada pelos devels e que foi apelidada pelos usuários de “suicide key” (reddit-1, reddit-2, reddit-3, debian-1, superuser-1, arch-1, ubuntu-1, Support.mozilla-1, QAStack-1, github-1, fedora-1, blog-1, blog-2, VNTWeb).

Uma pseudo-solução até foi implementada por eles, colocando uma opção de exibir um aviso caso a tecla seja pressionada, porém esta função nem sempre funciona (bugzilla-3), como aqui em casa por exemplo.

Foi necessário a mozilla foundation entrar em crise para eles finalmente implementarem na versão que está atualmente em beta uma opção no about:config para desabilitar a famigerada “suicide key”. Ou seja, foi literalmente gasto tempo de desenvolvimento para evitar que os usuários conseguissem resolver um problema criado pela própria mozilla foundation, outra ação vinda do ego dos desenvolvedores.

Na minha opinião, o grande vilão desse tipo de ação é projeto grande nas mãos de poucas pessoas (como os dois casos que citei), já que em projetos grandes e com um número absurdo de ramificações como o kernel linux ou o python têm esse tipo de problema (ego do desenvolvedor) de desenvolvimento é bastante mitigado.

2 curtidas

Cada projeto tem uma governança. Divergências são conciliadas via hard ou soft-forking, mudanças na governança ou via patching autônomo pelo usuário dissidente, já que o código é aberto. É preciso compreender isso, porque faz parte do modelo de desenvolvimento.

Eu concordo com as medidas restritivas implantadas pelo projeto KDE. Da minha parte, nada a fazer. A ideia de que limita o usuário é falaciosa, porque o usuário não foi impedido de alterar o código. E, antes do software chegar na máquina do usuário, ele saiu do upstream, foi compilado e empacotado (e talvez patcheado) pelo downstream e, só aí, instalado ou embarcado naquela máquina.

Você pode chamar de ego ou do que quiser, mas é assim que funciona. Governança + mão na massa (e geralmente essas duas coisas caminham juntas). Em mais de 21 anos ninguém escreveu um patch suficientemente bom para ser incorporado pelo downstream?

Não existem vilões. O software livre/de código aberto simplesmente não opera dentro de uma noção clientelista.

2 curtidas

Nesse caso faz sentido essa é uma ótima forma de ferrar com o sudores e com o sudo -H com a sua pasta pessoal inteira, isso é pra evitar users que seguem tutoriais aleatórios na Internet sem ler, dá pra contornar isso fácil, a linha só fica maior que é pro usuário ter certeza de que tá fazendo algo que não deveria:

pkexec env DISPLAY=${DISPLAY} XAUTHORITY=${XAUTHORITY} KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true [app do KDE, dolphin, kwrite, kate…]

2 curtidas

Se não existissem essas medidas, os usuarios, principalmente os leigos, poderiam fazer um estrago gigante no sistema.

1 curtida

E qual a intensão disso então ? Proteger o usuário dele mesmo ? O cara pegou uma distro linux, instalou, escolheu a DE e precisa ser protegido dele mesmo ? Se essa fosse a ideia, a pessoa permanecia no windows.

Vi agora seu edit: Eu sei que existe forma de burlar a proteção, o lance é que se o cara for ferrar com o sistema dele com comandos de terminal que ele não entende, ele não precisa de de dolphin, kate ou qualquer outro programa assim, um simples “dd” ou um “rm -rf” pode acabar com tudo de forma mais fácil do que abrindo um gerenciador de arquivos em root.

Aliás, se o cara é leigo a esse ponto, simplesmente retirar elementos da interface gráfica que ele usa já é motivo suficiente para tornar a máquina dele inútil e sua única solução passa a ser “formatar”.

1 curtida

A vantagem de um projeto gerador de ativos é inegável; tanto que, no Mundo Linux, três das principais distribuições estão vinculadas a projetos empresariais, sendo que uma tem vínculo com a IBM e outra com uma organização de investimentos globais (EQT, atual dona da SUSE).

Mesmo as grandes distros fundamentadas nos trabalho de grandes comunidades recebem apoios variados de grupos empresariais.

No entanto, a força de grandes comunidades, por si mesma, é fundamental ao Linux, e muito responsável pela evolução e amadurecimento desse sistema. Este é um fator indissociável, e Canonical, Red Hat e SUSE bem sabem aproveitá-lo para fortalecer seus produtos.

1 curtida

Entendo o objetivo dessas restrições: proteger o usuário dele mesmo. Entretanto, isso é efetivo ou até mesmo uma atitude esperta?
Obs.: entender o objetivo é diferente de concordar

Se o usuário necessita fazer alguma coisa com privilégios root, ele usará a conta de super-usuário de qualquer jeito, de uma forma ou de outra. Não seria melhor ele fazer isso com um programa com interface gráfica do que mexer “““no escuro””” (por favor, percebam as aspas) com o terminal?

Sou usuário do KDE Plasma, quando preciso alterar manualmente algum arquivo na partição raiz (o que é raro, não me lembro da última vez que fiz isso), simplesmente instalo o Thunar e uso o gerenciador de arquivos do XFCE para a tarefa.

2 curtidas

A resposta é: depende. E depende muito. Se o usuário for avançado, ele não vai fazer isso, porque sabe que existem nuances no processo. Como garantir a replicação das propriedades corretamente via GUI? A GUI omite várias configurações e, mesmo se as exibisse, o usuário saberia como manipulá-las?

Eu voto com o relator. Se o usuário quer mexer na raiz, ele que se garanta no terminal.

3 curtidas