Como configurar scanner HP Deskjet 2136 no Chakra Linux

Recentemente comprei uma impressora multifuncional HP Deskjet 2136. A escolha por HP é meio óbvia para quem usa GNU/Linux, a empresa oferece um ótimo suporte para esse sistema.

Antes de começar a configuração, veja se você tem instalado o pacote “hplip”, que é o pacote de drivers da HP para Linux. Também é preciso instalar o “Sane“, ele é quem dá suporte ao scanner. E o programa para scannear, no caso eu uso o “Simple Scan”.

Ao plugar a impressora na minha máquina a configuração inicial foi bem simples. Como uso Plasma Desktop, da comunidade KDE, fui direto no Menu > Configurações do sistema > Impressoras. Depois disso você clica no botão “Clique para adicionar uma nova impressora”:

screenshot_20161201_132041

Depois disso vai abrir uma janela solicitando que você insira sua senha de root. Feito isso basta clicar no botão “Ok” para dar prosseguimento a instalação:

screenshot_20161201_131632

Se o sistema identificar a sua impressora ela vai aparecer na lista, como mostrado abaixo. Então é só selecioná-la e clicar em “Próximo”:

Screenshot_20161201_132955.png

A próxima janela vai exibir a lista de drivers para a sua impressora. Você vai perceber que a lista oferecer o “hpijs” e “hpcups”. Eu sugiro que você escolha o “hpcups”, porque é o driver mais novo:

screenshot_20161201_135124

Depois é só clicar em “Concluir” e digitar sua senha de root.

screenshot_20161201_135229

Então sua impressora estará configurada!

Screenshot_20161201_135355.png

O próximo passo agora é configurar o scanner, caso ele não tenha sido identificado automaticamente pelo sistema, como foi o meu caso. Ao abrir o Simple Scan e clicar no botão “Preferências” e depois em “Origem da digitalização”, o programa mostrava apenas a minha webcam como dispositivo reconhecido.

screenshot_20161201_140054

A solução que consegui encontrar foi alterar o arquivo de configuração do sane, em /etc/sane.d/dll.conf. Como root eu acessei esse arquivo “dll” através do Vi e adicionei duas linhas: “hpoj” e “hpaio”. Isso fez com que o Simple Scan reconhecesse meu scanner e funcionasse direitinho. Se essas duas linhas já tiverem presentes no arquivo e tiverem comentadas, basta descomentá-las e testar se funciona também.

screenshot_20161201_142238

Não sei se funciona em todos os casos e não sei se funciona em todas as distros, funcionou comigo no Chakra e pode ser uma luz pra quem não sabe como resolver. Se a princípio isso não funcionar, você pode tentar ver se não é um problema também de permissão. Eu tive também que adicionar manualmente o ID da minha impressora em /usr/lib/udev/rules.d/, tal como é explicado na wiki do Arch.

Enfim, espero que esse breve tutorial tenha sido útil. Qualquer dúvida, basta comentar aqui embaixo e se eu souber responder, com certeza ajudarei 😉

Anúncios

6 carreiras essenciais em software livre para quem não programa

Por Nithya Ruff.

Link para o texto original em inglês aqui.

business_incentives
Imagem: opensource.com

Um sinal da maturidade de um movimento é quando as carreiras nele se tornam uma possibilidade. Este parece ser o caso com o software livre.

Quando comecei a trabalhar no software livre em 1999, isso era uma pequena parte do que eu fazia. Minha empresa, SGI, queria começar a vender servidores baseados em Linux, e minha tarefa era criar um processo para a comercialização de Linux. Hoje chegamos a um ponto em que software de código aberto está em quase todas as áreas de tecnologia. E enquanto nós muitas vezes ainda pensamos nisso como código e desenvolvedores, um ecossistema inteiro evoluiu em torno do software livre — e que inclui muitas carreiras em tempo integral. Esses papéis são muito necessários na medida em que o software livre amadurece, e permitem que mais gente como nós, que acreditamos no poder de desenvolvimento colaborativo, se envolva.

Para ajudar aqueles que procuram se envolver com software livre profissionalmente, aqui estão algumas das funções mais populares e emergentes.

Gerenciamento de comunidade

Este é, de longe, o papel mais amplamente conhecido no software livre e emergiu rapidamente à medida em que os projetos começaram a crescer. Gerentes de comunidade geralmente vêm de dentro do projeto e o conhecem bem, entendem a cultura do código aberto, têm habilidades de gerenciamento de projetos, e reúnem a equipe. Eles também organizam treinamentos, stands em conferências, reuniões de planejamento, etc., e muitas vezes intervém e lidam com o que for necessário para tornar o projeto bem sucedido.

Alguns dos melhores gerentes de comunidade que eu conheço são Jono Bacon do GitHub, Dawn Foster (ex-Puppet Labs), e Jeffrey Osier-Mixon do Projeto Yocto. A melhor maneira de aprender mais sobre gerenciamento de comunidade é ler o livro do Jono, The Art of Community, ou o livro da Dawn, Companies and Communities.

Documentação

Uma das áreas mais críticas para a adoção mais ampla de código aberto é a documentação— usuários, novos desenvolvedores, e até mesmo os desenvolvedores atuais dependem dela. Às vezes, escritores profissionais ou especialistas em documentação voluntários fazem o trabalho de documentação de um projeto, mas normalmente essa pessoa é um desenvolvedor. A documentação é um ótimo lugar para alguém novo se envolver e um ótimo lugar para aprender sobre um projeto. Ao se voluntariar para escrever a documentação para uma pequena parte do código, você pode se familiarizar e crescer a partir daí.

Uma das melhores especialistas de documentação que conheço é Anne Gentle. Ela é a líder de documentação na OpenStack, um projeto muito grande, com muitas partes móveis. Write the Docs e API Strategy and Practice são dois recursos que Anne usa para crescer e aprender.

Área Jurídica

Funções na área jurídica emergiram rapidamente na medida em que licenças de código aberto introduziram nuances para a prática da lei de licença. Dentro de uma empresa, os advogados aconselham sobre o uso de código aberto, compliance, contribuições e criação de políticas. Esta pessoa é muitas vezes um advogado tradicional que aprendeu conforme o uso de código aberto pela empresa cresceu.

Equipes jurídicas da comunidade podem estar na Software Freedom Conservancy ou Free Software Foundation, ajudando projetos e desenvolvedores com questões legais sobre coisas como a conformidade da licença. Advogados particulares, muitas vezes, prestam consultoria para startups, grandes empresas e projetos sobre questões de software livre. Você pode aprender mais sobre questões legais em SCaLE e LinuxCon, e em livros como o de Heather Meeker, Open (source) for business: A practical guide to open source licensing.

Ser bom com lei de código aberto requer um grande senso de compreensão das normas comunitárias e do sentimento, e não apenas a aplicação pura da lei. Alguns dos melhores advogados de código aberto que eu conheço são Eileen Evans da HP,  Lisa LaForge da SanDisk, e  Heather Meeker em O’Melveny & Myers LLP. Confira também a Open Invention Network (OIN), que é um consórcio de patentes defensivas compartilhadas com a missão de proteger o Linux. Há muitos advogados e educadores qualificados lá, como Deb Nicholson. Eles trabalham muito duro para proteger o desenvolvimento aberto de trolls de patentes e litígios.

Marketing

Marketing em software livre é uma atividade muito importante e pode ocorrer de várias formas. Marketing em uma empresa que vende um produto baseado em software livre é uma forma. Você precisa explicar por que os produtos baseados em software livre são inovadores, onde você como uma empresa agrega valor na versão comercial, e como você reduz o risco para as empresas que querem software livre, mas não querem os riscos.

Projetos de código aberto muitas vezes precisam de marketing, mas o evitam. Tracey Erway da Intel e eu tivemos a ideia de “advocacy” para o software livre quando fizemos o marketing para o Projeto Yocto. Advocacy pode ajudar projetos a arrecadarem dinheiro, recrutar mais colaboradores, e se conectarem com mais usuários.

Por último, o movimento software livre como um todo precisa se sensibilizar e divulgar as suas vitórias e sucessos. Fundações como a Linux Foundation e OpenStack Foundation fazem isso para o movimento. Todos nós precisamos ser evangelistas de projetos de software livre. Esta é uma forma de contribuir.

Para saber mais sobre o marketing em software livre, veja este vídeo que Tracey e eu fizemos há alguns anos:

Educação e jornalismo

Ainda existe uma grande necessidade de educação sobre como o software livre funciona, como se envolver, e os riscos a ele associados. Não há ninguém que sabe isso melhor do que Deb Nicholson, diretora de outreach na OIN. Ela é uma figura respeitada e reconhecida em eventos de software livre, que fala sobre patentes, licenças e as razões para adotar o software de código aberto.

A educação é um papel para aqueles que são apaixonados  por software livre e são bons comunicadores. Outra forma como a comunidade tem feito essa educação é através do jornalismo de tecnologia. Jornalistas e evangelistas como Rikki Endsley destacam questões e eventos importantes de software livre. Jornalistas mainstream, como Steven J. Vaughn-Nichols e Swapnil Bhartiya, também se tornaram uma parte da comunidade e ajudam a construir consciência e credibilidade para o software livre.

Líder de software livre em uma empresa

Uma das funções novas e emergentes é liderar a área de software livre de uma empresa. Estas áreas são chamadas de muitas coisas em diferentes empresas: programas de código aberto, estratégia de código aberto, e padrões e códigos abertos. Pessoas nessa função coordenam todas as coisas relacionadas a software livre em uma empresa e são os principais contatos para as organizações e fundações de software livre.

O foco do escritório de software livre de uma empresa depende das razões de negócios para seu envolvimento com isso. Uma empresa pode querer utilizar a metodologia de desenvolvimento de código aberto para melhorar a colaboração, focar em compliance, ou controlar a percepção do trabalho de código aberto da empresa.

Eu lidero o escritório de código aberto da SanDisk e essa tem sido uma das funções mais gratificantes que eu tenho realizado. Eu trabalho com engenheiros, advogados, gerentes de produto, executivos e com a comunidade todos os dias. É preciso uma pessoa que esteja confortável em transitar entre vários assuntos, de assuntos jurídicos em um dia para ferramentas de engenharia no outro. É preciso também de alguém que seja um agente de mudança e possa encorajar as empresas tradicionais a olharem para a inovação aberta. Alguns exemplos são: Chris DiBona no Google, Ibrahim Haddad na Samsung, Imad Sousou da Intel, e Guy Martin da AutoDesk.

Há necessidade de tantas outras funções em comunidades de software livre, como tradução, testes e organização de evento. Se você tem ideias sobre esses campos, deixe-nos um comentário ou escreva-nos em open@opensource.com.

LaKademy 2015: Returning to the beginning

ArteLakademy2015_0

Exactly five years I came to Salvador to attend my first KDE event. It was the debut of Akademy-BR and my debut as a community contributor. At the time, I was already using KDE for 3 years but I had not contributed to the community of software that I always liked. It was the perfect time to start! 🙂

Me, younger, thinner and a padawan :)
Me at the Akademy-BR 2010, younger, thinner and a padawan 🙂

Since then I never stopped. I was increasingly strengthening the ties with the community and dedicating part of my time to it. I became part of the translation team. And I became also (inevitably) part of the promo team, presenting talks, participating in many events such as KDE representative. Lately I have also worked with artwork, producing promotional material for the events we participate in and the events we organize. This LaKademy art, for example, was made by me 🙂

Well, but let’s talk about the event itself!

This Lakademy I dedicated myself to work with the translation of Plasma 5, the Techbase wiki and some KDE texts. Once the translation of Plasma 5 is almost complete, I did not have much work to be done, only some Gcompris strings still needed translation. The Techbase wiki is being updated since much there still refers to the Plasma 4 and we are already porting everything for the Plasma 5. So, I did not translate many pages because I did not want spend my time with things that are (or will be soon) obsolete.

I also committed myself to do some promotional material for the FISL, an event that we will participate in July, with a KDE stand selling gifts and doing activities on the community. I started doing some arts for t-shirts, stickers and coffee cups, but I not yet finalized it. Well, I’m not exactly a designer, right? 🙂 But I do my best.

LaKademy 2015 group photo
LaKademy 2015 group photo

I also took the opportunity of the event to migrate some things from our old wiki, which we no longer use, to our new site. There were many translation tutorials on the old wiki in our translation team page that were outdated and had some obsolete parts. I migrated all of these tutorials for the new site, I created a new page for our team and I deleted many obsolete things about KBabel and KDE 3 that were in these tutorials. The idea is to turn off this old wiki after migrate the contents that have not yet been migrated. Basically is just missing the history of our events, I did not have time to migrate during LaKademy.

In addition to this migration work, I also created some new pages on our website. I translated the KDE manifesto and I created a page for it in pt_BR, as well as the KDE Community Code of Conduct.

Well, besides, I mentored some people that appeared during the event interested in using and contributing to KDE. Some of them were interested in the translation work and I explained how it was the translation process and how our community worked. I hope that this event will bring us new contributors 🙂

Photos of the event can be seen here.

I would like to thank the support of KDE e.V. that once again believed in us and in our event. I would also like to thank immensely for all donors of our fundraising campaign for the LaKademy. You were very important in this process! 🙂

O Android é realmente software livre?

O texto abaixo foi publicado originalmente por Richard Stallman no site do The Guardian sob o título Is Android really free software? e republicado no site do Projeto GNU sob o título Android and Users’ freedom. Nele Stallman, precursor do movimento software livre, fala um pouco sobre suas objeções em relação ao sistema Android, criado pela Google para rodar em dispositivos portáteis. Leitura recomendada para quem deseja entender um pouco melhor a, por vezes obscurecida, relação entre Android, GNU e Linux!

A tradução do texto foi feita por mim, portanto, sintam-se à vontade para sugerir qualquer correção dela.

Até que ponto o Android respeita a liberdade do seu usuário? Para um usuário de computador que valoriza a liberdade essa é a questão mais importante a fazer sobre qualquer sistema de software.

No movimento software livre, nós desenvolvemos software que respeita a liberdade dos usuários, então nós e vocês podemos escapar de softwares que não fazem isso. Por outro lado, a ideia de “open source” foca em como desenvolver código, é uma corrente de pensamento diferente cujo principal valor é a qualidade do código ao invés da liberdade. Assim, a preocupação aqui não é se o Android é “aberto”, mas se ele permite que os usuários sejam livres.

Android é um sistema operacional principalmente para celulares, que consiste em Linux (Kernel do Torvalds), algumas bibliotecas, uma plataforma Java e alguns aplicativos. Linux à parte, o software do Android versões 1 e 2 foram a maior parte desenvolvidos pela Google; a Google o lançou sob a licença Apache 2.0, que é uma licença permissiva de software livre sem copyleft.

A versão do Linux incluída no Android não é inteiramente software livre, uma vez que ela contém “blobs binários” não livres (assim como a versão de Torvalds do Linux), alguns dos quais são realmente utilizados em alguns dispositivos Android. Plataformas Android usam outro firmware não livre e também as bibliotecas. Além desses, o código fonte do Android versões 1 e 2, como divulgado pela Google, é software livre – mas esse código não é suficiente para fazer funcionar o dispositivo. Alguns dos aplicativos que geralmente vêm com o Android são não livres também.

Android é muito diferente do sistema operacional GNU/Linux porque contém muito pouco do GNU. Na verdade, o único componente em comum entre o Android e o GNU/Linux é o Linux, o kernel. As pessoas que erroneamente acham que “Linux” se refere a inteira combinação GNU/Linux fica enrolado por esses fatos, e fazem afirmações paradoxais como “Android contém Linux, mas não é Linux”. Se evitarmos partir dessa confusão, a situação é simples: Android contém Linux, mas não GNU; assim, Android e GNU/Linux são em sua maior parte diferentes.

No Android, Linux, o kernel, continua sendo um programa separado, com seu código fonte sob uma licença GNU GPL versão 2. Combinar Linux com um código sob a licença Apache 2.0 seria violação de copyright, já que a GPL versão 2 e Apache 2.0  são incompatíveis. Os rumores de que a Google tinha de alguma forma convertido o Linux à licença Apache estão errados. Google não tem o poder para alterar a licença do código do Linux, e nem tentou. Se os autores do Linux permitiram a sua utilização sob a GPL versão 3, então esse código poderia ser combinado com um código licenciado sob Apache, com a combinação poderia ser liberado sob a GPL versão 3. Mas o Linux não foi liberado dessa forma.

Google cumpriu com as exigências da GNU Licença Pública Geral para Linux, mas a licença Apache sobre o resto do Android não exige liberação do código fonte. Google disse que nunca publicaria o código fonte do Android 3 (com exceção do código do Linux). O código do Android 3.1 também foi retido, tornando o Android 3, além do Linux, software não livre puro e simples.

Google disse que reteve o código do 3 porque estava bugado, e que as pessoas deveriam esperar para o próximo lançamento. Isto pode ser um bom conselho para as pessoas que querem simplesmente rodar o sistema Android, mas os usuários devem ser os únicos a decidir isso. De qualquer forma, desenvolvedores e tinkerers que desejam incluir algumas das mudanças em suas próprias versões podem usar esse código muito bem.

Felizmente, a Google mais tarde lançou o código fonte para o Android 3.* quando lançou a versão 4 (também com código fonte). O problema acima acabou se tornando uma aberração temporária em vez de uma mudança na política. No entanto, o que acontece uma vez pode acontecer de novo.

Em todo caso, a maior parte do código fonte de várias versões do Android foi liberada como software livre. Isso significa que produtos que usam essas versões do Android respeitam a liberdade do usuário? Não, por várias razões.

Primeira de todas, a maioria deles contém aplicativos não livres do Google para conversar com serviços como YouTube e Google Maps. Estes não são oficialmente parte do Android, mas isso não torna o produto bom. Há também bibliotecas não livres; se elas fazem parte do Android é um ponto discutível. O que importa é que várias funcionalidades precisam delas.

Mesmo os arquivos executáveis que são oficialmente parte do Android podem não corresponder aos lançamentos de código fonte da Google. Os fabricantes podem alterar esse código, e muitas vezes eles não liberam o código fonte para suas versões. A GNU GPL exige que eles distribuam o código para suas versões de Linux, se cumprirem. O resto do código, sob a licença permissiva Apache, não os obriga a liberar a versão do código que eles realmente usam.

Uma mudança que alguns fabricantes fazem no Android é a inclusão de um oculto pacote de vigilância geral, como o Carrier IQ.

Replicante, uma versão gratuita do Android que suporta apenas alguns poucos modelos de telefone, substituiu muitas dessas bibliotecas, e você pode ficar sem os aplicativos não livres. Mas há outros problemas.

Alguns modelos de dispositivos são projetados para impedir os usuários de instalar e usar o software modificado. Nessa situação, os executáveis não são livres, mesmo se eles forem feitos a partir de fontes que estão livres e disponíveis para você. No entanto, alguns dispositivos Android podem permitir acesso root para que os usuários possam instalar software diferente.

Importantes firmwares ou drivers são geralmente proprietários também. Estes abrangem o rádio da rede de telefone, Wi-Fi, bluetooth, GPS, gráficos 3D, a câmera, o viva voz, e em alguns casos, o microfone também. Em alguns modelos, alguns destes drivers são livres, e há alguns que você pode ficar sem – mas você não pode ficar sem o microfone ou o rádio da rede de celular.

O firmware de rede de telefone vem pré-instalado. Se tudo o que fez foi sentar lá e executar, poderíamos considerá-lo como equivalente a um circuito. Quando insistimos que o software em um dispositivo de computação deve ser livre, nós podemos esquecer o firmware pré-instalado que nunca será atualizado, porque ele não faz diferença para o usuário, ele é um programa em vez de um circuito.

Infelizmente, neste caso, seria um circuito nocivo. Recursos maliciosos são inaceitáveis, não importa como eles são implementados.

Na maioria dos telefones Android, este firmware tem tanto controle que poderia transformar o produto em um dispositivo de escuta. Em alguns, ele controla o microfone. Em alguns, ele pode assumir o controle total do computador principal, através de memória compartilhada, e pode, assim, anular ou substituir qualquer software livre que você instalou. Com alguns modelos é possível exercer um controlo remoto deste firmware, e, assim, do computador do telefone, por intermédio da rede de rádio do celular. O ponto de software livre é que temos controle de nossa computação, e esta não se qualifica. Embora qualquer sistema de computação possa TER bugs, estes dispositivos podem SER erros. (Craig Murray, em Murder in Samarkand, relata seu envolvimento em uma operação de inteligência que remotamente converteu um desavisado celular não Android em um aparelho de escuta.)

Em todo caso, o firmware de rede do telefone em um dispositivo Android não é equivalente a um circuito, porque o hardware permite a instalação de novas versões e isto é realmente feito. Já que ele é um firmware proprietário, na prática apenas o fabricante pode fazer novas versões – usuários não podem.

Colocando esses pontos juntos, nós podemos tolerar firmware não livre de rede do telefone, fornecido novas versões dele que não serão carregadas, ele não pode assumir o controle do computador principal, e pode se comunicar apenas quando e como o sistema operacional livre optar por isso. Em outras palavras, ele tem de ser equivalente ao circuito, e esse circuito não deve ser nocivo. Não há obstáculo para a construção de um telefone Android que tenha essas características, mas não sabemos de nenhum.

Cobertura de imprensa recente do Android concentra-se nas guerras de patentes. Durante 20 anos de campanha pela abolição das patentes de software, nós alertamos que tais guerras poderiam acontecer. As patentes de software poderiam forçar a eliminação de recursos do Android, ou mesmo torná-lo indisponível. Veja endsoftpatents.org para obter mais informações sobre o porque patentes de software devem ser abolidas.

No entanto, os ataques de patentes e as respostas da Google não são diretamente relevantes para o tema deste artigo: como os produtos Android abordam um sistema ético de distribuição e como eles ficam aquém. Este assunto merece a atenção da imprensa também.

Android é um passo importante no sentido de uma ético celular software livre, controlado pelo usuário, mas há um longo caminho a percorrer. Os hackers estão trabalhando no Replicant, mas é um grande trabalho apoiar um modelo de telefone novo, e aí permanece o problema do firmware. Mesmo que os telefones Android de hoje sejam bem menos ruins que os smartphones da Apple ou  Windows, eles não podem dizer que respeitam a sua liberdade.