Introdução aos Runlevels e comandos de gerenciamento do Systemd

Quinta, 06 de Novembro de 2014 às 14:38. Carla Schroder. Exclusivo

cgroups, ou control groups, estão presentes no kernel Linux há alguns anos, mas não vem sido muito utilizado até o systemd.

Em tempos antigos nós tínhamos runlevels estáticos. systemd tem mecanismos para controle mais flexível e dinâmico do seu sistema.

Antes de entrarmos em mais aprendizado de mais comandos uteis do systemd, vamos dar uma pequena viagem na estrada na lembrança. Há essa esquisita dicotomia no Linux-land, onde o Linux e o FOSS estão sempre avançando e progredindo, e as pessoas estão sempre reclamando disso. É por isso que estou reduzindo todo esse tumulto anti-systemd a um grão de sal, por que eu me lembro quando:

• Pacotes eram ruins, por que usuários de Linux de verdade construíam tudo a partir do código fonte e mantinham controle estreito do que acontecia nos seus sistemas.
• Gerenciadores de resolução de dependências (Dependency-resolving) de pacotes eram ruins, por que usuários de Linux de verdade dependências manualmente.
• Exceto pelo apt-get, que sempre foi bom, então somente o Yum era ruim.
• Por que a Red Hat era a Microsoft do Linux.
• Yxi Ubuntu!
• Bú seu Ubuntu!

E por aí vai... como eu disse muitas vezes anteriormente, mudanças são perturbadoras. Elas mexem com o nosso fluxo de trabalho, que já não são coisas pequenas por que qualquer rompimento tem um verdadeiro custo de produtividade. Mas nós ainda estamos no estágio infantil da computação, então ela vai continuar mudando e avançando rapidamente por um bom tempo. Tenho certeza que você pessoas que estão presas na ideia de que uma vez que você compra algo, como uma chave inglesa ou uma peça de mobília ou um flamingo rosa ornamental de gramado, é para sempre. Essas são as pessoas que ainda estão rodando Windows Vista, ou Deus no ajude Windows 95 em algum PC antiquado, débil com um monitor CRT, e que não entende por que você continua bugado-os para que sejam substituídos. Ele ainda funciona, certo?

Que me lembra do meu grande triunfo em manter um computador antigo rodando bem depois que ele deveria ter sido aposentado. Era uma vez uma amiga que tinha esse 286 velhinho rodando alguma versão inadequada do MS-DOS. Ela o utilizava para algumas tarefas básicas como compromissos, diário, e um programinha velho de conta que eu escrevi para ela em BASIC para seu registro de verificação. Quem liga para atualizações de segurança, certo? Ele não está conectado a nenhuma rede. Então de tempos em tempos eu substituía o resistor e capacitor de falha ocasional, o suprimento de energia, e a bateria CMOS. E continuava levando. Seu velho e minúsculo monitor CRT ambar escurecia cada vez mais, e finalmente ele morreu depois de mais de 20 anos de serviço. Agora ela está utilizando um Thinkpad antigo rodando Linux para as mesmas tarefas.

Se há uma moral nessa tangente ela me escapou, então vamos nos ocupar com o systemd.

Runlevels vs. States

SysVInit utiliza runlevels estáticos para criar states diferentes para bootar, e a maioria das distros utilizam cinco:

• Single-user mode
• Multi-user mode sem serviços de rede iniciado
• Multi-user mode como serviços de rede iniciado
• System shutdown
• System reboot.

Particularmente, Eu não vejo muito valor pratico em ter múltiplos runlevels, mas lá estão eles. Ao invés de runlevels, o systemd lhe permite criar states, que lhe dá mecanismo mais flexível por criar configurações diferentes para bootar. Esses states são compostos de múltiplos arquivos unit empacotados dentro de targets (alvos). Os targets tem bons nomes descritivos aos invés de números. Arquivos unit controlam serviços, dispositivos, sockets, e montagens. Você pode ver como esses arquivos se parecem ao examinar os targets prefab que vem com o systemd, por exemplo /usr/lib/systemd/system/graphical.target, que é o padrão no CentOS 7:

[Unit]

Description=Graphical Interface

Documentation=man:systemd.special(7)
Requires=multi-user.target

Conflicts=rescue.target
After=multi-user.target

[Install]
Wants=display-manager.service
AllowIsolate=yes

Alias=default.target

Então, como os arquivos unit se parecem? Espreitemos um. Arquivos unit estão em dois diretórios:

• /etc/systemd/system/
• /usr/lib/systemd/system/

O primeiro é para nós atuarmos, e o segundo é aonde os pacotes os arquivos unit. O /etc/systemd/system/ leva precedência ao /usr/lib/systemd/system/. Urrah, humano sobre a maquina. Esse é o arquivo unit para o servidor Web Apache:

[Unit]

Description=The Apache HTTP Server

After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify

ExecStart=/usr/sbin/httpd/ $OPTIONS -DFOREGROUND
EnvironmentFile=/etc/sysconfig/httpd

ExecStop=/bin/kill -WINCH ${MAINPID}
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
KillSignal=SIGCONT
PrivateTmp=true

WantedBy=multi.user.target

[Install]

Esses arquivos são bem compreensiveis mesmo para recém-chegados ao systemd, e os aquivos são bastante simples do que um arquivo SysVInit init, como esse snippet a partir do /etc/init.d/apache2 exibe:

SCRIPTNAME="${0##*/}"

SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then

        if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
        else

                DIR_SUFFIX=

O arquivo inteiro tem 410 linhas.

Você pode visualizar as dependências unit, e sempre é surpreendente para mim como eles são complexos:

$ systemctl list-dependencies httpd.service

cgroups

cgroups, ou control groups (grupos de controle), tem estado presente no kernel Linux há alguns anos, mas não tem sido muito utilizado até o systemd. A documentação do kernel diz: "Control Groups fornecem um mecanismo por agregar/particionar conjuntos de tarefas, e todas as suas futuras children, nos grupos hierárquicos com comportamento especializado."Em outras palavras, ele tem o potencial para controlar, limitar, e alocar recursos em múltiplos jeitos uteis. systemd utiliza o cgroups, e você pode vê-los. Ele exibe sua arvore de cgroup inteira:

$ systemd-cgls

Você pode gerar uma visualização diferente com o bom e antigo comando ps :

$ ps xawf -eo pid,user,cgroup,args

Comandos uteis

Esse comando recarrega o arquivo de configuração de uma daemon, e não seu arquivo de de serviço systemd. Utilize isso quando você fizer uma alteração de configuração e quiser ativar-lo como a menor descrição, como esse exemplo para o Apache:

# systemctl reload httpd.service

Recarregar um arquivo de serviço para-o completamente e reinicia um serviço. Se não estiver rodando, Ele o inicia:

# systemctl restart httpd.service

Você pode reiniciar todas as daemons como um único comando. Isso reinicia todos os arquivos unit, e re-cria toda a arvore de dependência do systemd:

# systemctl daemon-reload

Você pode rebootar, suspender, e desligar como um usuário comum não privilegiado:

$ systemctl reboot

$ systemctl suspend

$ systemctl poweroff

Como sempre, há muito, muito mais a se aprender sobre o systemd. Aqui vamos nós de novo, mais um Linux Init: Introdução ao systemd e Entendendo e utilizando o Systemd são ótimas introduções ao systemd, com links para recursos mais detalhados.

Fonte:  Introdução aos Runlevels e comandos de gerenciamento do Systemd

 QUER APRENDER A UTILIZAR O BTRFS NO FEDORA, ENTÃO VENHA APRENDER LINUX COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

NÃO! "Open Source" não significa "Suporte gratuito"

    A treta começa com um software chamado Raccoon. Raccoon é uma plataforma open source (sob os termos da licença Apache 2) e independente para download de aplicativos da Google Play Store. O objetivo é te dar acesso seguro aos aplicativos Android sem ter que comprometer o seu smartphone.

    O problema quando as pessoas começaram a reportar bugs e recebiam a seguinte resposta como no exemplo mostrado em seu blog:

Usuário: Oi, eu gostaria de reportar um bug em sua aplicação.

Eu: Ótimo! Então por favor, abra um ticket de suporte.

Usuário: Mas, parece que eu preciso pagar por isso?

Eu: Daí?

Usuário: Eu só quero te dizer que seu app está quebrado, assim você pode concertar.

Eu: Sim, essa é uma solicitação de suporte, por favvor abra um ticket.

Usuário: ...

    Pode parecer estranho a situação que acabaram de ler por estarmos acostumados a receber as coisas tudo de graça no mundo open source MAS, algo que eu sempre digo é:

Não confundam Free e open source software com Freeware.

    A palavra inglesa free pode realmente confundir as pessoas uma vez que pode significar tanto livre quanto de graça. Por exemplo na frase food for free (comida de graça e não comida livre). porém a palavra free em free software refere-se a liberdade (daí software livre) enquanto que em freeware refere-se a de graça (software gratuito).

    O problema é que a falta de leitura faz com que as pessoas que defendem software livre com unhas e dentes passem a condenar e abominar os que cobram por algum tipo de valor financeiro pelo serviço sendo que tudo isto já é previsto dentro das licenças (no caso da GPL é previsto a liberdade de distribuir cópias do software e até mesmo cobrar se achar interessante ou se desejar. Já a Apache 2 (que é open source) prevê no ultimo termo (termo nono) que você pode escolher oferecer e cobrar uma taxa por suporte, garantia, indenização e outros direitos). Ou seja, não há nada de errado no que o autor está fazendo.

    Em seu blog o autor menciona que ele desenvolveu a aplicação para solucionar seu problema e consequentemente disponibilizou gratuitamente junto ao seu código fonte. Então, se o procurarem para reportar um bug, ou as pessoas podem enviar o patch incluso no bugreport ou pagar para que ele solucione o problema (o que é totalmente lógico). O autor diz fica feliz em ajudar, mas além do seu tempo ser valioso, vender o suporte é o que mantem as luzes acesas já que aquilo deixou de ser livre quando começou a lhe custar algum valor como manter o servidor web funcionando.

As informações podem ser lidas clicando aqui.

    As pessoas ainda não entenderam que o real sentido de software livre e de código aberto não se trata de receber e utilizar programas gratuitamente; trata-se de lhe oferecer condições de realizar o seu trabalho sem restrições. O que nos remete à celebre frase de Linus Torvalds:

Você suspira pelos bons tempos do Minix-1.1, quando os homens eram homens e escreviam seus próprios "device drivers"? Você está sem um bom projeto em mãos e deseja trabalhar num S.O. que possa modificar de acordo com as suas necessidades? Acha frustrante quando tudo funciona no Minix? Chega de noite ao computador para conseguir que os programas funcionem? Então esta mensagem pode ser exactamente para você. :-)

    Pois é, era exatamente sobre poder realizar seu trabalho que Linus Torvalds estava se referindo. Na época, mesmo o Minix sendo de código aberto, possuía restrições em seu licenciamento onde não era permitido a modificação do seu código fonte. Ou seja, as pessoas estavam limitadas a o que podiam ou não fazer no Minix mesmo podendo visualizar o código e até serem capazes de melhorá-lo. Até que é compreensível e uma ideia interessante já que a intenção era aguçar a habilidade de programação. Mas essa ideia de qualquer jeito frustrava a maioria dos seus usuários (e foi exatamente isso que inspirou Linus a escrever tal frase).

    Então uma dica muito interessante a ser dada aos que criticam esta atitude acreditando que, o que  moralmente deveria ser feita, é disponibilizar o software (inclusive o código fonte) simplesmente é:

Desenvolva o seu projeto e o disponibilize gratuitamente e não ache que as pessoas devam fazer o mesmo simplesmente porque você acredita.

    Então se você também quiser me ajudar, não esqueça de conferir o meu curso de migração para Linux e aprenda Linux de verdade comigo e assim você me ajuda a manter o meu canal e o  meu blog ;) 

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Uma opinião nas diferenças entre BSD e Linux (Dando Crédito aonde o Crédito é Devido)

Perguntas e respostas (por Jesse Smith)

/*

 Pessoas me perguntaram sobre as diferenças entre Linux, BSD e Hurd. Então para ajudar a todos melhor compreender sobre essas diferenças, resolvi publicar esse post que traduzi do wbsite distrowatch.

 O único sistema que ressalto aqui que não cobre esse artigo que traduzi é o Hurd. Basicamente ele é um microkernel que ainda está em desenvolvimento e vai saber la quando ficará pronto, por que todo sistema microkernel que eu conheço ou nunca saíram de beta ou foram descontinuados ou nem estão prontos para colocar para produção.

 Os únicos dois sistemas microkernel que eu gosto são o L4 e o Spartan.

 Por Gabriel Costa

*/

Perguntas curiosas sobre pinguins e demônios: O lema do seu website diz "Use Linux, BSD." Você poderia falar um pouco a respeito das diferenças, como são comparados um com o outro? Você recomendo um ou o outro?

DistroWatch answers: É difícil falar o que torna Linux e BSD diferente um do outro (ou um similar ao outro) por que existem tantas variantes de cada. No exato momento, existem literalmente centenas de distribuições Linux e uma boa quantidade sabores de BSDs a escolha. Então realmente, quando examinar os dois,as pessoas normalmente tem que fazer tal usando generalizações. Como um exemplo, muitos dos nomes das grandes distribuições Linux tem instalador gráfico fácil de utilizar (mas algumas distros não). Por outro lado, muitos sistemas BSDs não tem um instalador GUI (grafical user interface), mas ao menos alguns tem. Como você pode imaginar, com tantos projetos diferentes de ambos os lados, há quase sempre exceções para as regras.

Pode ser mais fácil olhar o que eles tem em comum. Ambos Linux e BSD pertencem a família do sistema operacional UNIX (alguém pode frisar que BSD é um descendente do UNIX, onde Linux é um sistema operacional UNIX-like) e eles tem muito em comum superficialmente. Os vários sistemas Linux e BSD geralmente tem o mesmo layout de sistema de arquivos, usam ferramentas de linhas de comando similar e geralmente podem compilar e executar o mesmo software.

Do meu ponto de vista, a grande coisa que eu notei quando se alterna entre Linux e BSD são as maneiras que os pacotes são administrados. Sistemas Linux, ou GNU/Linux, tendem a ser feitos de módulos pequenos (pacotes). Eu visualizo uma distro GNU/Linux como um modelo químico onde os átomos são interligados. Você pode adicionar ou remover pedaços e reformular o modulo. Cada “átomo” é um pedaço pequeno do um todo. Os BSDs, por outro lado, dividem seus pedaços do sistemas diferentemente. O kernel e algumas das ferramentas básicas são administradas sob um projeto. Então outro sofwtare, tal como ambientes desktop e office são colocados no topo daquela fundação. E eu acho que essa diferença indica que as diferenças importantes entre os dois campos são mais filosófico do que técnico. 

Em minha experiência muitos dos usuários de Linux que eu encontro são mais idealísticos quando se vem para seus software e suas liberdades de software. Um bom exemplo disso é o conceito “Year of the Linux Desktop ” que aparece em uma base regular. Muitos dos grandes nomes de distribuições Linux vem como mais amigáveis do que os projetos BSD. Há exceções em ambos os lados, mas a comunidade Linux aparenta recrutar novos membros mais ativamente.

Desenvolvimento aparenta progredir em metas diferentes e em estilos ligeiramente diferentes. Pegue o som por exemplo. No lado do Linux, nós saltamos do OSS para o ALSA para PulseAudio. No campo do BSD nós vimos ao invés disso o trabalho para melhorar o OSS. Quando o ZFS surgiu, o FreeBSD adotou e portou o novo sistema de arquivos para seu OS. No campo do Linux nós vimos esforço para criar o ext4, mais um esforço para criar Btrfs (lê-se butterfs ou betterfs, sátira de sistema de arquivos manteiga ou sistema de arquivos melhor em inglês) e um projeto para portar o ZFS como um módulo. Os desenvolvedores no BSD aparentam fazer um esforço concentrado para conseguir uma coisa funcionando propriamente enquanto os desenvolvedores do Linux oferecerão múltiplas soluções. Há uma piada na comunidade BSD que os programadores Linux estão cerca de três anos a frente... em mudar a sua ideia.

A maior parte da minha experiência é com os sistemas Linux, então é geralmente o sistema operacional que eu recomendo as pessoas. Dessa maneira eu poderei ajudá-las melhor em troble-shoot, no momento, eu acho que Linux tem ligeiramente melhor suporte a driver também, que é importante para usuários domésticos. No entanto, acho que é importante equilibrar isso com algumas indicações de profissionais experientes. Com isso em mente eu pedi a Kriss Morre (fundador do projeto PC-BSD) e Matt Nuzum (da equipe da Canonical) para ponderar sobre assunto.

DW: Kris, que diferenças você vê entre BSD e Linux?

KM: há um numero importante de diferenças no cerne do BSD e Linux. Quando você instala FreeBSD, você está obtendo um sistema operacional completo, kernel + userland, que é projetado para funcionar de forma muito coerente. No lado do Linux, seu “sistema operacional” pode variar grandemente de distro para distro, ou mesmo de instalação para instalação, por que Linux no seu coração é só um kernel (núcleo) e um subconjunto de várias ferramentas a critério do empacotador/instalador.

Além do sofwtare em si, há uma distinção importante da licença também. Ambas licenças open-source que defendem a liberdade, no entanto liberdade significa coisas diferentes para pessoas diferentes. O kernel Linux e muitos dos seus componentes são liberados sob varias formas da licença GPL, a qual requer usuários / desenvolvedores para aderir a seus termos e condições a fim de manter qualquer desenvolvimento / uso compatível a GPL, ao dar o código fonte de volta a comunidade, restringindo DRM (GPL3) e mais. A licença BSD por outro lado é também open-source, mas carrega consigo nenhuma expectação ou demandas no uso futuro / desenvolvimento. O código licenciado-BSD pode ser tomado e obtido para qualquer propósito, sem ter que se preocupar com “ficar dentro do compatível”.

DW: E a respeito de similaridades?

KM:Enquanto no coração ambos sistemas são diferentes, eles compartilham mesmo muito em comum um com o outro. A maioria das mesmas aplicações podem e executam mesmo em ambos, de serviços tal qual Apache, à Desktop e ferramentas produtividade tal qual KDE, OpenOffice, FeireFox, Wine e mais.

DW: Por que você presente que BSD é uma plataforma melhor?

KM: A licença é uma enorme vantagem para mim, mais o jeito que o núcleo do sistema operacional é projetado parece muito mais "natural" e intuitivo. A estabilidade do processo de seu desenvolvimento é uma enorme vantagem, ABI's são muito estáveis e nos lidam com menos "bit-rot" do que eu tenho experimentado em vários sabores de Linux.

DW: você pode identificar algo que você sente que a comunidade Linux faz melhor do que a BSD?

KM: por causa das mudanças do Linux tão rapidamente eles estão com frequência a frente de nós em certas áreas, como suporte a hardware. Um monte de aplicações desktop open-source são desenvolvidas no Linux, então isso pode levar um pouco mais de tempo para um lançamento ser feito no ports tree do FreeBSD, embora isso tem se tornado muito melhor ao longo dos anos.

DW: Obrigado , Kris. Matt, quais são algumas das diferenças entre Linux e BSD?

MN: Linux é uma re-implementação ou copia do sistema Unix que compartilha um ancestral comum com o BSD. Foi projetado para paracer familiar para os usuários UNIX e BSD (e de muitas maneiras ele consegue), no entanto a arquitetura subjacente para criar o sistema é bastante diferente em alguns modos importantes. Por exemplo, configurar um firewall, escolher quais programas iniciam automaticamente ou instalar um driver para seu sistema serão diferentes entre BSD e Linux.

DW: Quais são algumas similaridades entre os dois sistemas?

MN: As filosofias UNIX e FOSS são o vinculo comum. Muitas linhas de comando e ferramentas gráficas são as mesmas ou funcionam as mesma em ambos os sistemas. Como um exemplo, os desenvolvedores para ambos os sistemas Linux e BSD utilizam OpenSSH para conectar-se aos seus servidores, Vim ou Emacs para editar seus código fonte e GCC para compilá-lo. Ambos servidores BSD e Linux executam normalmente o servidor web Apache, Samba e CUPS para arquivo e compartilhamento de impressora e MySQL ou PostgreSQL para trabalho com banco de dados. Se você tem um desktop BSD ou Linux então você provavelmente executa GNOME ou KDE sobre o X.org e navega na internet com o Firefox.

DW: Por que você acha que Linux é a melhor plataforma?

MN: Antigamente Linux era uma copia do UNIX, seguindo os rastros dos gostos do BSD e Solaris. No entanto, nos últimos 10 anos se foi a frente em muitos aspectos chave. O primeiro catalizador para mudança foi melhor suporte a driver para computadores PCs comuns a qual lhe deu grade impulso. Então, mais usuários e desenvolvedores adotaram Linux, ele começou a se tornar a plataforma para inovação e BSD e UNIX ficaram para trás. Agora é comum ver novas atualizações de sofwtares e melhoras lançados primeiro para Linux e então se tornam compatíveis com BSD.

DW: Por favor compartilhe algo que você gosta nos sistemas da família BSD.

MN: Existem muitas variantes do BSD, cada uma com méritos diferentes. Dois exemplos excelentes são OpenBSD e NetBSD. 

Os desenvolvedores do OpenBSD são motivados por um desejo de manter seu track-recored de excelência em segurança. Eles revisam seus códigos e implementam recursos que ajudam a assegurar que o sistema operacional resistirá mesmo a ataques mais motivados. Além disso, ele também historicamente ostenta uma das mais robustas pilhas de rede TCP/IP. Esse dois recursos combinam para torná-lo uma excelente escolha para infraestrutura de rede. 

NetBSD tem como um valor central o desejo de acomodar uma grande variedade de plataformas. Roda em uma coleção diversa de computadores então seus mantenedores lutam para criar um sistemas que é flexível e portável.

DW: Obrigado, Matt.

Fonte: 

http://distrowatch.com/weekly.php?issue=20100802

Lançada libabigail 2.0

Lançada libabigail 2.0

 Libabigail (abreviação de Application Binary Interface Generic Analysis and Instrumentation Library) é uma  biblioteca do Linux para a construção, manipulação, serialização e de-serialização de artefatos de ABI que pode ser usado por exemplo para detectar incompatibilidade entre diversos lançamentos de bibliotecas compartilhadas ou entre o kernel e os módulos.

 A libabigail provê um conjunto de ferramentas em linha de comando para comparar as interfaces de binários ELF resultantes da compilação de programas em C e C++.

 Dodji Seketeli (seu autor) anunciou o lançamento da versão 2.0 que traz como principais mudanças a migração da licença GPLv3 para Apache 2.0 com exceções ao LLVM (o fim da GPL é praticamente inevitável); a mudança para C++11 (ha intenção de construir a libabigail nas distribuições Linux com versões do GCC 4.8.5 e mais recentes); suporte ao DWARF5 que permite a biblioteca gerar binários com toolchains mais recentes baseadas no LLVM e no GCC e mais 145 novidades entre correções de bugs e melhorias.

 Obrigado aos que revisaram o texto deste artigo.

Você pode baixar a libabigail 2.0 no próprio mirror do kernel Linux

A documentação pode ser baixada clicando aqui

E suas ferramentas você pode baixar aqui.

CLIQUE AQUI E VENHA APRENDER LINUX DE VERDADE.

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

A queda da GPL?

Top licenças Open Source no Github

Ao longo de sua adoção no Linux a GPL ganhou força, respeito, destaque e até autoridade. As empresas não querem saber se o software é livre ou não, elas querem que o serviço delas sejam feitos. Se o software livre atende a seus serviços, Logo elas irão favorece-lo. Por conta desse caso de sucesso (Linux), as próprias empresas e projetos passaram a adotar a GPL acreditando ser correto, confiável e até passando a fazer contribuições com muita frequência para os projetos uma vez que eles se tornaram viáveis como no artigo "Para que serve a liberdade?"

"Para que serve a liberdade?"

 A GPL fazia sentido (e acredito que ainda poderia fazer sentido) como descrito no artigo "As incríveis vantagens proporcionadas pelo software livre e de código aberto", quando a GPL era a GPL.

"As incríveis vantagens proporcionadas pelo software livre e de código aberto"

 Há pessoas que nem sabem o porque estão a defendendo. Isso eu falo pessoas que são considerado gente grande e aclamada. Para começar, a maioria das pessoas tem a concepção errada do que é software livre e de código aberto. Elas veem software livre como software de graça. Muitos acabam sendo nesse aspecto agindo como sangue sugas querendo as coisas de mão beijada não retribuindo de alguma forma.

 O que está errado é o fato de que os amantes de Linux e da liberdade do software tratam Linux como GNU. Apesar de Linux fazer uso de ferramentas do GNU, os dois são projetos distintos (e é isso que muita gente ate hoje não mentalizou). Essa imagem de GNU/Linux precisa ser desvinculada das mentes das pessoas. Não existe GNU e Linux como uma coisa só. Linux não deve satisfação para o GNU e nem vice versa.

 Depois do meu vídeo GPL e o capitalismo e toda discussão no vídeo, resolvi escrever este artigo mostrando como anda a GPL depois da versão 3 e depois de toda a atitude (errada) tomada pela FSF:

 Acho incrível é que mesmo depois de mostrado tudo isso, há pessoas que continuaram e que continuarão batendo na mesma tecla. Mas com as atitudes (até radicais) da FSF, indivíduos, projetos e empresas passaram a temer a GPL. O que era para ser liberdade acabou passando ser uma ditadura.

 Como resultado disso, a GPL passou a entrar em declínio como pode ser visto no gráfico abaixo extraído do site Red Monkey onde a GPLv2 era predominante em 2010 e passou em 2017 a ser a licença MIT (tendo essências das licenças BSD com algumas modificações)

Acompanhamento de adoção das licenças open source entre 2010 e 2017

No site BlackDuck também mostra o gráfico top licenças Open Source, demonstra a mesma coisa tendo a MIT predominando, a GPLv2 em segundo lugar, a Apache em terceiro (nessa entra forte o Android) e depois a GPLv3:

Top licenças open source

 A GPL fazia sentido na versão 2. Hoje ela perdeu a sua característica, essência e sentido com a vinda da GPLv3. O único e real motivo que a FSF criou a GPLv3 foi pelo medo de se tornar politicamente irrelevante. Ela queria que o destaque fosse ao GNU e não Linux (tornando o GNU o garoto Estrela). Tenham cuidado, pois vocês podem estar defendendo gnu e não a liberdade.

Confiram também como anda a adoção das licenças no proprio site Github (e qual melhor né)

Como anda a adoção da GPL no Github

• Redmonk
• Opensource.com
• Black Duck software
• Github

Novatec Editora lança livro “Analítica de dados com Hadoop” e “Primeiros passos com React”

Título ensina a usar técnicas estatísticas e de machine learning em grandes conjuntos de dados

Sempre lembrando que comprando no próprio site da editora Novatec com o cupom de desconto TOCADOTUX, você ganha 20% de desconto em qualquer livro (a promoção é valida até 30 de Dezembro).

O ecossistema do Hadoop é perfeito para o uso de técnicas estatísticas e de aprendizado de máquina (machine learning) em grandes conjuntos de dados. Em vez de ter como foco a implantação, as operações ou o desenvolvimento de softwares, você pode se concentrar nas análises particulares que pode fazer, nas técnicas de armazém de dados oferecidas pelo Hadoop e em fluxos de trabalho de alta ordem que esse framework é capaz de gerar.

É o que ensina o livro Analítica de dados com Hadoop, lançado pela Novatec Editora. Com ele, os cientistas e analistas de dados aprenderão a usar diversas técnicas que variam da escrita de aplicações MapReduce e Spark com Python ao uso de modelagem avançada e gerenciamento de dados com Spark MLlib, Hive e HBase. Também conhecerão os processos analíticos e os sistemas de dados disponíveis para desenvolver e conferir eficácia aos produtos de dados capazes de lidar com – e que, na verdade, exigem – quantidades enormes de dados.

O leitor de Analítica de dados com Hadoop também entenderá os conceitos principais do Hadoop e do processamento em cluster, obterá conhecimentos sobre gerenciamento de dados, mineração e armazém de dados em contexto distribuído usando Apache Hive e HBase, aprenderá a utilizar padrões de projeto e algoritmos analíticos paralelos para criar Jobs de análise de dados distribuídos e muito mais. 

Sobre os autores:

Benjamin Bengfort é cientista de dados e trabalha para terminar seu doutorado na Universidade de Maryland, onde estuda aprendizado de máquina e computação distribuída. Programador profissional por ofício, escreve sobre uma grande variedade de assuntos, de Processamento de Linguagem Natural e ciência de dados com Python a analítica (analytics) com Hadoop e Spark.

Jenny Kim é engenheira sênior de big data e trabalha tanto com softwares comerciais quanto em ambientes acadêmicos. Tem experiência significativa em trabalhos com dados de larga escala, aprendizado de máquina e implementações de Hadoop em ambientes de produção e de pesquisa. Atualmente, trabalha com a equipe de Hue, na Cloudera.

REACT

Livro ensina a construir uma aplicação web baseada em React, a tecnologia de código aberto do Facebook

Quer aprender a construir aplicações sofisticadas com React, a tecnologia de código aberto do Facebook? Se você tiver familiaridade com a sintaxe básica de JavaScript, o livro Primeiros passos com React, lançado pela Novatec Editora, vai te ensinar a construir componentes – os blocos de construção básicos da React – e a organizá-los em aplicações de larga escala.

Depois de entender como React funciona, você construirá uma aplicação personalizada Whinepad completa para ajudar os usuários a classificar vinhos e a guardar anotações.
O livro ensina a:

• Instalar React e escrever sua primeira aplicação web “Hello world”.
• Criar componentes React personalizados, usando-os juntamente com componentes DOM genéricos.
• Construir um componente de tabela de dados que permita editar, ordenar, pesquisar e exportar seu conteúdo.
• Utilizar a extensão de sintaxe JSX como alternativa a chamadas de função.
• Configurar um processo de construção simples, de baixo nível, que ajude você a se concentrar na React.
• Construir uma aplicação personalizada completa que permita armazenar dados no cliente.
• Usar as ferramentas ESLint, Flow e Jest para verificar e testar o seu código à medida que sua aplicação evoluir.
• Administrar a comunicação entre os componentes usando Flux.

Com a leitura de Primeiros passos com React, o leitor entenderá rapidamente por que alguns desenvolvedores consideram React essencial para o desenvolvimento de aplicações web.

Sobre o autor

Stoyan Stefanov é engenheiro do Facebook. Anteriormente na Yahoo, ele criou a smush.it  – uma ferramenta de otimização de imagens online – e foi arquiteto da ferramenta de desempenho YSlow 2.0. Stoyan é autor de Padrões JavaScript(Novatec) e Object-Oriented JavaScript (O’Reilly), além de ser blogueiro (phpied.com) e palestrante frequente em eventos, incluindo O'Reilly Velocity Conference, JSConf, Fronteers e muitos outros.

tipidee: Um novo web server

 tipidee é um web server desenvolvido por Laurent Renot, autor das ferramentas de skarnet.org que  vocês viram aqui no meu ultimo post.

Leia o artigo: O dia que Laurent Bercot calou Richard Stallman: Eu não uso GNU, eu uso Linux!

 O tipidee possui suporte a HTTP 1.0 e 1.1 tendo compatibilidade com a RFC 9112. Apesar de ainda implementar um conjunto muito limitado de subconjunto de funcionalidade opcional no HTTP 1.1, o tipidee implementa todas as partes obrigatórias e é utilizável com HTTP e HTTPS. O tipidee pode ser executado como serviço do inetd (que tradicionalmente não é conhecido por ter bom desempenho), ou do s6-tcpserver, ou ou s6-tlsserver (para HTTPS).

 A ideia por do tipidee é trazer as melhores características dos dois modelos de web servers existentes atualmente e que não há nada em meio a termo . Desses dois modelos temos temos:

1. Os grandes e poderosos (como nginx e Apache como exemplos) mas que a simplicidade não é uma preocupação e pode ser trocada por recursos, integração com ecossistemas maiores ou apenas velocidade de serviço.
2. Os pequenos (como busybox httpd, bozohttpd, ou vários httpds da ACME Labs) que focam em ser fáceis de fazer deploy para servir tanto em protótipos quanto em ambientes como embarcados.

 Existem na verdade várias propostas de serem pequenos e mínimos mas que são escritos em linguagens que o runtime utiliza mais recursos do que todos o ecossistema da skarnet.org; e não existe um focado no que é proposto no tipidee:

• Usabilidade com HTTPS sem a necessidade de embarcar o código com a biblioteca TLS. O que significa delegar a camada TLS para um super-server e não executar o trabalho do socket em si. A importância disso é que se torna mais difícil de manter, de fazer builds, de gerar pacotes, de distribuir e menos seguro quando o web server é amarrado a biblioteca TLS.
• Suporte a HTTP 1.1 com conexões persistentes e não somente a 1.0.
• Suporte a CGI real, não somente a NPH.

 Existe o lighttpd, por exemplo, foi desenvolvido como uma prova de conceito para resolver o problema c10k. O nome tipidee é uma espécie de forma menor (assim como o código) de dizer h-t-t-p-d. Está sob a licença ISC. 

tipidee - a small and fast HTTP/1.1 server (skarnet.org)

Manpage do tipidee no sr.ht

Leia também O dia que Laurent Bercot calou Richard Stallman

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

PAGORA TAMBÉM DISPONÍVEL NA PLATAFORMA WORKOVER

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Se a newlib é tão boa para embarcados, por que não foi adotada pelo Android?

Android 9 Pie

 Escrevi ontem a noticia sobre um novo patch para a newlib que irá melhorar seu desempenho significativamente. A newlib foi adquirida pela Red Hat quando esta comprou a cygnus solution. Se buscarmos informações em vários sites, veremos como a newlib é bem mencionada por vários profissionais da área de embarcados.

 Daí, surge a questão:

 "Se newlib é a biblioteca mais indicada por muitos profissionais para embarcados, por que então criaram a Bionic para o Android?"

 A questão é um pouco mais complicada, e para isso temos que entender como a comunidade do Android é regida. A primeira coisa que temos que entender é que há uma política no Android de não haver aplicações sob GPL em seu user space e se houver, você não poderá utilizar o nome Android em seu sistema, vindo a ter que remover o nome Android de todo o sistema operacional que está fornecendo.

 Nesse caso, como quem rege o user space é a biblioteca C e a Bionic está sob clausula 2 da BSD (coisa que a Bionic herdou do freeBSD e do NetBSD uma vez que a Bionic é derivada de porções de bibliotecas dos dois sistemas), acho que fica claro o motivo se cruzarmos os fatos. A ideia por trás disso é evitar problemas futuros com o uso de GPL nas aplicações do Android; problemas que já ocorreram com outros projetos e empresas. Por conta desta politica, a maior parte de suas aplicações em user space estão sob licença Apache e algumas partes sob outras licenças como o próprio kernel que está sob GPL (lembrando, não há problema quanto ao kernel pois ele não atua no user space e sim no kernel space), seu terminal padrão que desde a versão 7 do sistema é o toybox está sob 0BSD e vale mencionar até o microkernel Fuschia roda no processo de boot do Android.

 Há um misto de tecnologias que são utilizadas no desenvolvimento do Android e expliquei neste vídeo aqui:

 E o que isso tudo tem a ver com a newlib? A newlib é uma biblioteca que possui um misto de licenças, sendo uma delas a GPL e com isso, acaba dificultando a adoção da newlib no Android. O que poderia ser feito nesse caso é utilizar as partes que não estejam sob GPL para a criação de algo novo ou até mesmo serem incorporadas a bionic.

 Honestamente eu espero verdade é que a bionic venha a ser substituída pela musl. Agora, se você trabalha em um projeto baseado no Android (uma distribuição baseada no Android) e não se importa quando ao uso do nome, aí tanto faz qual biblioteca e sob qual licença que vai rodar no user space, você só não poderá usar o nome Android. Podem haver outras implicações, mas essa é a maior.

LINK PARA O CURSO DE SHELL SCRIPT DO MATEUS MÜLLER

Curso COMPLETO para a certificação CompTIA Linux+ e LPIC-1 do Mateus Müller do canal 4Fasters
Udemy