[Tutorial] Instalação manual do Ambiente de Execução Java (JRE) no *Ubuntu Linux

[Sampayu]

Obrigado pelo excelente e didático tutorial! Uma sugestão em relação a este trecho:

1.5. CRIE A PASTA DE PLUGINS DO SEU NAVEGADOR.
[...]
Mozilla Firefox:
Não é necessário fazer nada, pois a pasta já existe em /usr/lib/firefox-addons/plugins

Nota: a partir da versão 21.0 do navegador Mozilla Firefox, o plugin só irá funcionar se o atalho para ele estiver dentro de /usr/lib/firefox-addons/plugins, ao invés de em /usr/lib/firefox/plugins.

Estou usando o Firefox 30, e parece que o local de armazenamento dos plugins mudou de novo; agora é /usr/lib/mozilla/plugins/.

E, a propósito, tentei tudo o que você sugeriu aqui: os passos do tutorial, e os que você sugeriu em respostas seguintes... e não rolou. Na maioria das tentativas, o verificador no site java.com indicava a versão correta do Java (7u60, que é a mais atual e por isso usei para instalar). O mais perto que chego é a exibição da página onde o BB pede a senha (o applet já teria rodado?), mas o quadro onde ficariam os campos de formulário nessa página está vazio. Assim:



Estou usando LMDE (Mint baseado no Debian Testing). Queria evitar de usar um kernel alternativo para isso (como a Thelma sugeriu), mas acho que já testei todas as alternativas que encontrei por aí. Se tiver alguma outra sugestão, agradeço!

Atualizando: consegui! Com o Java da Sun (+plugin) instalado conforme este tutorial, funcionou usando o seguinte comando:

Código Selecionar Expandir

setarch x86_64 –uname-2.6 firefox &
Já tinha tentado essa forma de iniciar o firefox, mas provavelmente quando estava ainda com o OpenJDK. A fonte da dica é este e-mail de uma lista do Debian.

Oi, desculpe a demora, está ficando cada vez mais difícil eu conseguir arrumar tempo para responder perguntas do fórum.

O endereço /usr/lib/mozilla/plugins não pertence ao Firefox: esse endereço é um caminho "genérico" do sistema que (pelo menos em tese) é reconhecido por todos os navegadores que tenham sido construídos usando a arquitetura Mozilla. Exemplos de navegadores Mozilla: Firefox, Opera, Iceweasel, Cyberfox, IceDragon etc. Portanto, se você puser aquele link "sunjava" dentro de /usr/lib/mozilla/plugins a priori todos os navegadores Mozilla que você tiver no seu sistema deverão enxergar esse link e passar a reconhecer o plugin que você instalou em /opt/java.

De maneira geral, quando aquela página em branco aparece é porque o applet começou a ser executado mas logo foi interrompido (ou entrou em "loop infinito") por causa de algum problema, como por exemplo incompatibilidade entre o JRE e o bytecode do applet (teclado virtual), erro na identificação da arquitetura do navegador e/ou do sistema operacional etc. No seu caso, pelo visto o problema era a identificação da arquitetura do navegador (64 bits).

Eu nunca havia visto alguém necessitar do comando setarch para conseguir rodar um navegador, rs. Isso deve ter a ver com o fato de você estar usando uma versão testing. Ou será que o seu Java e o seu navegador estão com arquiteturas distintas (32 bits e 64 bits)? Se (por exemplo) o seu sistema operacional for de 64 bits, é necessário instalar o Firefox de 64 bits e o Java de 64 bits. Mas se tudo estiver com a mesma arquitetura, então há algum problema nessa versão do seu navegador que faz com que ele forneça a informação errada da arquitetura dele, daí a necessidade de usar o comando setarch, no momento em que o navegador é inicializado, para forçar seu navegador a informar ao sistema operacional que a arquitetura correta dele (navegador) é 64 bits (x86_64)...

...ou de repente o problema nem é a arquitetura (32 bits / 64 bits), mas sim a versão de release do kernel: daí a necessidade de usar --uname-2.6 para indicar que o kernel do seu LMDE é versão 2.6. Vai saber... Eu não uso LMDE, então o que você pode fazer é verificar por si mesmo (usando o comando uname -a) qual é a arquitetura do seu sistema operacional e a versão do kernel, e daí confrontar isso com os parâmetros que você está usando no comando setarch.

Em tese, se o seu sistema operacional é de 64 bits e o seu Firefox também é de 64 bits, não há porque usar o x86_64 no comando setarch: provavelmente o problema é só a versão de release do kernel que é diferente de 2.6 e está acarretando algum problema na hora de o JRE (via plugin) executar o applet e passar para o applet a versão do kernel do seu sistema.

[Sampayu]

Lubuntu versão 14.04 realizei todo procedimento, porém o Chrome não reconhece o plugin, já o Firefox reconheceu e está funcionado para BB e Caixa.
Será que o Chromium reconhecerá? Vou instalá-lo pra saber.

Como informou o rodrigo.miguel, a Google abandonou o suporte à tecnologia de plugins NPAPI para os navegadores Chrome e Chromium, por isto você não vai mais conseguir usar o plugin Sun Java nos navegadores da Google. Para mais informações, leia a introdução deste tutorial ou então este meu post.

[Sampayu]

Eu instalei no meu Debian conforme o seu tutorial, show de bola, funciona direitinho, mas não sei se é algum problema novo com o BB ou se eu fiz algo de errado, mas o site quando eu vou entrar com a senha fica todo branco, anexo uma foto. No Ruindows 7 tá funcionando normal.

https://drive.google.com/file/d/0B7bzIqNnWABjZThrUHNUWXB2UkU/edit?usp=sharing

Ontem eu instalei o Ubuntu 14.04 LTS. Quase não acrescentei pacotes. Mas está tudo atualizado.

Código Selecionar Expandir

$ sudo apt-cache policy openjdk-7-jre icedtea-7-plugin
openjdk-7-jre:
  Instalado: 7u55-2.4.7-1ubuntu1
  Candidato: 7u55-2.4.7-1ubuntu1
  Tabela de versão:
*** 7u55-2.4.7-1ubuntu1 0
        500 http://br.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     7u51-2.4.6-1ubuntu4 0
        500 http://br.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
icedtea-7-plugin:
  Instalado: 1.5-1ubuntu1
  Candidato: 1.5-1ubuntu1
  Tabela de versão:
*** 1.5-1ubuntu1 0
        500 http://br.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Código Selecionar Expandir

$ java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

Acessa o Banco do Brasil. Quero só fazer constar que após um acesso, uma vez, eu percebi uma tela como a do screenshot de @lgustavod.

A questão que quero solucionar é esta:



Aparece algumas vezes até o final do acesso. Não quero que apareça. A configuração tem de valer para outro usuário, ou por usuário.

Seguem as hiperligações:

• JAR File Manifest Attributes for Security
• Preventing RIAs from Being Repurposed

Este tutorial é sobre Java da Sun. No Java da Sun (supondo que ele esteja instalado em /opt/java) basta abrir o painel de controle (executar o comando /opt/java/jre/bin/jcontrol), clicar na aba Segurança, depois em Editar Lista de Sites..., daí clicar no botão Adicionar, digitar o endereço https://www2.bancobrasil.com.br e sair dando "Ok" para confirmar e fechar as janelas. Pronto: quando o applet do banco solicitar ao plugin a execução do JRE, o JRE verá que a origem do applet é https://www2.bancobrasil.com.br e daí não mais fará aquela verificação de segurança.

O OpenJDK também possui um painel de controle, geralmente acessível via menu da interface gráfica do seu sistema. Esse painel de controle do OpenJDK provavelmente possui um recurso similar (de lista branca). Basta adicionar o endereço https://www2.bancobrasil.com.br à lista branca. O comando de execução desse painel de controle varia conforme a versão e local de instalação do seu OpenJDK, mas no menu da interface gráfica do seu sistema deve haver um atalho para esse painel de controle, dentro de um submenu que tenha algum nome tal como "Java", "Configurações" ou "Sistema". Se não encontrar esse painel de controle, experimente rodar o comando jcontrol diretamente no terminal: talvez funcione.

[Sampayu]

Realmente isso tem acontecido com a 14.04.
Toda vez aparece essa telinha repetidamente.
Tentei marcar, desmarcar, responder Yes e No, em vão.

E não apenas para acesso ao BB. Em mais de uma máquina vi ocorrendo com o Itaú e com a CEF.
Coisa do Java ou do Icedtea?

Assumindo que o seu banco é o Banco do Brasil e que você já atualizou seu Java para a versão mais atual (que no momento é a 7u65), experimente acessar o jcontrol (Painel de Controle Java. Vide o item 3.4 deste tutorial), daí, no painel de controle clique na aba Segurança, depois em Editar Lista de Sites... e então clique no botão Adicionar. Digite este endereço:

https://www2.bancobrasil.com.br

Agora saia clicando em "Ok" até fechar o painel de controle. Feche o navegador e reexecute-o. Acesse novamente a página do Banco do Brasil. Se der erro de carregamento do navegador, atualize a página algumas vezes clicando no botão "Recarregar esta página" ou pressionando a combinação de teclas Ctrl Shift R

[alexandre.mbm]

no painel de controle clique na aba Segurança, depois em Editar Lista de Sites... e então clique no botão Adicionar. Digite este endereço:

https://www2.bancobrasil.com.br

Eu já sabia que com o Java da Oracle o problema não existe ou é facilmente contornável. Mas eu e o alevian temos usado o Java aberto.

Código Selecionar Expandir

$ java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

O OpenJDK Java 7 Policy Tool não é um "Painel de Controle".

O IcedTea Web Control Panel tem um aba Security, mas sem funcionalidade Editar Lista de Sites. As coisas nele funcionam de modo diferente.

Este tutorial é sobre Java da Sun.

Desculpe-me, então.

O OpenJDK também possui um painel de controle, geralmente acessível via menu da interface gráfica do seu sistema. Esse painel de controle do OpenJDK provavelmente possui um recurso similar (de lista branca).

Talvez eu não esteja sabendo usá-lo.

Código Selecionar Expandir

$ ls /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/
itweb-settings  java  javaws  keytool  orbd  pack200  policytool  rmid  rmiregistry  servertool  tnameserv  unpack200

[Sampayu]

Há quem defenda não se falar nesses termos de "comercial ou não" quando se fala de software livre ou de código aberto. Pois software livre é comercializável, inclusive sob GPL.

Sobre o uso da palavra comercial: eu fiz esse uso apenas para fins didáticos (facilitar a compreensão). A ideia ali era "comercial" como sinônimo de "de código fechado". De qualquer modo, a Oracle muito provavelmente pagou pela biblioteca de fontes que utiliza em sua implementação fechada (já que essa biblioteca de fontes é fechada). Também havemos de levar em consideração que o Java da Oracle usado no Java SE (Java Platform Products) é vendido, comercializado (vide o pricing list da Oracle). Então há elementos "comerciais" (do Direito Comercial) dentro dessa implementação. Enfim: faz sentido usar a palavra "comercial". E convenhamos: essas terminologias todas (comercial, freeware, GPL, open source, livre etc.) provocam uma confusão danada na cabeça das pessoas. Por isto eu procuro simplificar. Mas, claro: se eu simplificar demais e com isto acabar ocasionando algum erro conceitual grosseiro, aí é melhor corrigir mesmo, ser mais rígido.

O  JDK oficial da Oracle é que é freeware. Ele é distribuído gratuitamente, mas não é software livre e não está sob GPL. Freeware, software livre e código aberto são três conceitos distintos.

As diferenças conceituais eu conheço, mas nem sempre me preocupo tanto com elas, já que elas são mais fonte de confusão do que de impacto efetivo no uso que fazemos desses aplicativos (digo: para nós, usuários finais, essas diferenças conceituais muito raramente causam algum impacto ou têm grandes consequências. Não é como no caso de uma empresa que deseja distribuir um software e daí precisa de fato saber que tipo de software ele é, qual licença utiliza etc.).

Mas no trecho em que eu disse que o OpenJDK é freeware eu realmente errei. E detectei outros pontos em que há erros conceituais. Vou analisar meu post e corrigi-lo. Obrigado, Alexandre.

Sim, o JDK oficial da Oracle é mantido fechado com fins comerciais. Não significa dizer que um software precisa ser privativo (proprietário) para ter fins comerciais.

Certamente que não. Eu mesmo já doei dinheiro para os desenvolvedores de diversos aplicativos de código aberto, livres ou não, entre eles os desenvolvedores destes aplicativos que eu aprecio bastante:

• Audacity
• LibreOffice
• NoScript
• OpenTTD
• Transmission
• VLC

Como este post pode vir a ser lido por outras pessoas, neste link é possível conhecer as diferenças conceituais entre freeware, open source, software livre, GPL etc.

[alexandre.mbm]

E convenhamos: essas terminologias todas (comercial, freeware, GPL, open source, livre etc.) provocam uma confusão danada na cabeça das pessoas. Por isto eu procuro simplificar. Mas, claro: se eu simplificar demais e com isto acabar ocasionando algum erro conceitual grosseiro, aí é melhor corrigir mesmo, ser mais rígido.

Muita confusão é oriunda de "simplificações" que tornam-se deturpações e desinformação. Daí a minha preocupação.

no uso que fazemos desses aplicativos (digo: para nós, usuários finais, essas diferenças conceituais muito raramente causam algum impacto ou têm grandes consequências. Não é como no caso de uma empresa que deseja distribuir um software e daí precisa de fato saber que tipo de software ele é, qual licença utiliza etc.)

Eu desejo que cada pessoa que opte por Software Livre o faça conscientemente.

Também havemos de levar em consideração que o Java da Oracle usado no Java SE (Java Platform Products) é vendido, comercializado (vide o pricing list da Oracle)

Depois vou ler o que significam esses produtos: Java SE Advanced Desktop, Java SE Advanced e Java SE Suite. Eu falava da JRE como freeware.

[Sampayu]

no painel de controle clique na aba Segurança, depois em Editar Lista de Sites... e então clique no botão Adicionar. Digite este endereço:

https://www2.bancobrasil.com.br

Eu já sabia que com o Java da Oracle o problema não existe ou é facilmente contornável. Mas eu e o alevian temos usado o Java aberto.

Código Selecionar Expandir

$ java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

O OpenJDK Java 7 Policy Tool não é um "Painel de Controle".

O IcedTea Web Control Panel tem um aba Security, mas sem funcionalidade Editar Lista de Sites. As coisas nele funcionam de modo diferente.

Este tutorial é sobre Java da Sun.

Desculpe-me, então.

O OpenJDK também possui um painel de controle, geralmente acessível via menu da interface gráfica do seu sistema. Esse painel de controle do OpenJDK provavelmente possui um recurso similar (de lista branca).

Talvez eu não esteja sabendo usá-lo.

Código Selecionar Expandir

$ ls /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/
itweb-settings  java  javaws  keytool  orbd  pack200  policytool  rmid  rmiregistry  servertool  tnameserv  unpack200

Como eu comento neste post, o IcedTea não é um JRE ou um JDK. Ele está mais para uma "suíte" de "peças de software" da qual uma ou mais partes podem ser úteis para uso conjunto com o OpenJDK.

Como os profissionais de TI dos bancos desenvolvem seus applets para que rodem no (e somente no) Sun Java (eles não se dão o trabalho de verificar a compatibilidade com o OpenJDK e outras implementações), eu não me estresso tentando fazer o OpenJDK funcionar igual a (ou funcionar tão bem quanto) o Sun Java: eu simplesmente instalo o Sun Java e pronto. Se o meu banco desenvolveu uma solução de segurança baseada em Java da Sun, é até melhor que eu use o Java da Sun, não apenas por questão de compatibilidade mas até mesmo por questões legais: se porventura ocorrer algum problema técnico e isso acarretar perdas financeiras para o cliente, o banco poderá querer argumentar que o problema só ocorreu porque o cliente estava usando uma implementação Java que não foi homologada pelo banco para uso com o software de segurança que esse banco disponibilizou. Isso pode facilmente virar uma batalha judicial. Como seguro morreu de velho e é minha obrigação contratual, enquanto cliente do banco, usar as soluções de segurança que o banco definiu para proteger ambas as partes (banco e cliente), o mais indicado é usar o Sun Java: pelo menos quando for acessar o banco. Para acessar outros websites (com os quais o usuário não tem nenhum contrato firmado), aí ok usar uma implementação Java diferente.

Claro que cada usuário é livre para fazer as escolhas que quiser (e essa é uma das vantagens de se usar um sistema GNU/Linux: a liberdade de escolha entre diferentes implementações de JRE). Mas particularmente eu vejo como um estresse e um risco desnecessário essa história de tentar a todo custo fazer o OpenJDK funcionar bem com os bancos. Embora o projeto do OpenJDK seja da Oracle, o código-fonte dele é diferente do do Sun Java e por isto os dois JRE funcionam diferentemente. Em websites rodando applets mais compatíveis, essa diferença não será sentida e daí o OpenJDK realmente poderá ser usado plenamente no lugar no Sun Java. Mas, em websites de bancos, pelo menos por enquanto o Sun Java ainda é o que funciona melhor. E, como comentei antes, há a questão contratual...

Faz muito tempo que não mexo com OpenJDK e IcedTea (embora eu os mantenha instalados e atualizados, no meu sistema). Quando estiver com um tempo livre eu vou investigar para ver se descubro algum modo de criar essa lista branca dentro do JRE do OpenJDK (ou se no plugin IcedTea-Web é possível estabelecer essa lista branca).

Abraço.

[alexandre.mbm]

eu simplesmente instalo o Sun Java e pronto

Eu fazia isso.

Se o meu banco desenvolveu uma solução de segurança baseada em Java da Sun, é até melhor que eu use o Java da Sun, não apenas por questão de compatibilidade mas até mesmo por questões legais: se porventura ocorrer algum problema técnico e isso acarretar perdas financeiras para o cliente, o banco poderá querer argumentar que o problema só ocorreu porque o cliente estava usando uma implementação Java que não foi homologada pelo banco para uso com o software de segurança que esse banco disponibilizou. Isso pode facilmente virar uma batalha judicial. Como seguro morreu de velho e é minha obrigação contratual, enquanto cliente do banco, usar a solução de segurança que o banco definiu para proteger ambas as partes, o mais indicado é usar o Sun Java. Pelo menos quando for acessar o banco. Para acessar outros websites (com os quais o usuário não tem nenhum contrato firmado), aí ok usar uma implementação Java diferente.

Aceito a argumentação. É o caminho certo. Voltarei a instalar o Java da Oracle. Quem usa o banco nem sou eu...

[Sampayu]

E convenhamos: essas terminologias todas (comercial, freeware, GPL, open source, livre etc.) provocam uma confusão danada na cabeça das pessoas. Por isto eu procuro simplificar. Mas, claro: se eu simplificar demais e com isto acabar ocasionando algum erro conceitual grosseiro, aí é melhor corrigir mesmo, ser mais rígido.

Muita confusão é oriunda de "simplificações" que tornam-se deturpações e desinformação. Daí a minha preocupação.

no uso que fazemos desses aplicativos (digo: para nós, usuários finais, essas diferenças conceituais muito raramente causam algum impacto ou têm grandes consequências. Não é como no caso de uma empresa que deseja distribuir um software e daí precisa de fato saber que tipo de software ele é, qual licença utiliza etc.)

Eu desejo que cada pessoa que opte por Software Livre o faça conscientemente.

Também havemos de levar em consideração que o Java da Oracle usado no Java SE (Java Platform Products) é vendido, comercializado (vide o pricing list da Oracle)

Depois vou ler o que significam esses produtos: Java SE Advanced Desktop, Java SE Advanced e Java SE Suite. Eu falava da JRE como freeware.

Eu cursei Licenciatura em Matemática. No curso, nós aprendemos muito formalismo matemático, e daí nos damos conta de como os nossos professores do ensino médio (antigo segundo grau), principalmente os professores de Matemática e de Física, "simplificaram a linguagem" - a ponto de cometerem alguns pequenos erros ou desvios conceituais ou formalísticos - para que nós, alunos secundaristas, conseguíssemos compreender melhor (ou mais facilmente, ou mais rapidamente...) certos conceitos. Por exemplo: quando um professor diz que y = 2x + 4 e manda você resolver essa equação funcional de duas variáveis, ele cometeu o erro de não dizer se x e y são variáveis que assumem valores numéricos reais ou naturais ou inteiros ou...

Outro exemplo de algo que muito comumente ocorre nas salas de aula: quando um professor de Física diz que um corpo pesa 3kg, ele está cometendo vários erros, pois [1] o peso de um corpo varia conforme a aceleração da gravidade (que por sua vez depende da altitude e da latitude desse corpo), consequentemente não faz sentido informar o peso de um corpo sem informar qual o valor da aceleração da gravidade no local em que o peso desse corpo foi medido, [2] "kg" é unidade de massa (não de peso), e [3] não existe equipamento metrológico no mundo que tenha tanta precisão a ponto de poder afirmar que um corpo tem exatamente 3kg de massa (por isto essa massa deveria ter sido informada juntamente com a incerteza do equipamento que a mediu. Por exemplo: 3,0 +/- 0,3 kg).

Mas esse excesso de formalismo tornaria uma aula de Física ou de Matemática [1] mais extensa, demorada, [2] mais chata e [3] mais cansativa e desanimadora. É por isso que os professores preferem abrir mão de parte do formalismo para simplificar a linguagem. E a lógica é a mesma nos meus textos. Eles não são a verdade absoluta: é de se esperar que os leitores façam como você fez, ou seja, estudem em outras fontes e aprendam mais, desenvolvam o senso crítico a ponto de conseguirem perceber que os meus textos não são perfeitos, que há conceitos que, num nível mais formal, podem vir a divergir do que eu escrevi.

Na minha opinião (que pelo que percebi é diferente da sua), essa "licença didática" não é algo assim tão negativo, principalmente porque o leitor interessado naturalmente irá, posteriormente, buscar mais informações por conta própria, como você já fez no passado (e por isto conhece as diferenças entre GPL, software livre, freeware etc.) e daí aprenderá por si mesmo as diferenças mais detalhadas que existem entre os conceitos. Mas ok, a sua opinião é diferente. Uma sugestão: você pode divulgar aquele link que forneci, espalhá-lo nas redes sociais etc., para que mais pessoas se familiarizem com as diferenças. Da minha parte, vou procurar me monitorar mais para não cometer desvios muito grandes, mas eu sei que se eu os cometer isso em nada impedirá, na prática, que os usuários entendam a mensagem que eu de fato quis transmitir: que, por exemplo, o OpenJDK e o Sun Java são duas implementações diferentes.

[Sampayu]

eu simplesmente instalo o Sun Java e pronto

Eu fazia isso.

Se o meu banco desenvolveu uma solução de segurança baseada em Java da Sun, é até melhor que eu use o Java da Sun, não apenas por questão de compatibilidade mas até mesmo por questões legais: se porventura ocorrer algum problema técnico e isso acarretar perdas financeiras para o cliente, o banco poderá querer argumentar que o problema só ocorreu porque o cliente estava usando uma implementação Java que não foi homologada pelo banco para uso com o software de segurança que esse banco disponibilizou. Isso pode facilmente virar uma batalha judicial. Como seguro morreu de velho e é minha obrigação contratual, enquanto cliente do banco, usar a solução de segurança que o banco definiu para proteger ambas as partes, o mais indicado é usar o Sun Java. Pelo menos quando for acessar o banco. Para acessar outros websites (com os quais o usuário não tem nenhum contrato firmado), aí ok usar uma implementação Java diferente.

Aceito a argumentação. É o caminho certo. Voltarei a instalar o Java da Oracle. Quem usa o banco nem sou eu...

Kkkk, você é uma figura, Alexandre. Mas eu gosto dos seus posts, você é uma pessoa que raciocina e tem senso crítico. Eu gosto disso, é muito bacana você ser assim.

[alexandre.mbm]

Por exemplo: quando um professor diz que y = 2x + 4 e manda você resolver essa equação funcional de duas variáveis, ele cometeu o erro de não dizer se x e y são variáveis que assumem valores numéricos reais ou naturais ou inteiros ou...

Outro exemplo de algo que muito comumente ocorre nas salas de aula: quando um professor de Física diz que um corpo pesa 3kg, ele está cometendo vários erros, pois [1] o peso de um corpo varia conforme a aceleração da gravidade (que por sua vez depende da altitude e da latitude desse corpo), consequentemente não faz sentido informar o peso de um corpo sem informar qual o valor da aceleração da gravidade no local em que o peso desse corpo foi medido, [2] "kg" é unidade de massa (não de peso), e [3] não existe equipamento metrológico no mundo que tenha tanta precisão a ponto de poder afirmar que um corpo tem exatamente 3kg de massa (por isto essa massa deveria ter sido informada juntamente com a incerteza do equipamento que a mediu. Por exemplo: 3,1 +/- 0,3 kg).

São "modelos" da Ciência, convenções por si mesmas. A maior parte de sua analogia está demasiadamente elástica.

A nomeação de todas as coisas, começando por aquelas encontradas na natureza (tais como animais e plantas) também é convenção, isso é verdade. Mas são convenções incomparavelmente mais enraizadas do que aquelas dos "modelos" que a Ciência elabora e propõe. De tal modo que não convém chamar carro de avião e macaco de galinha.

O modelo que o professor de física de ensino médio usa não é o mesmo modelo usado no ensino superior. Dentro do modelo, o professor precisa manter a consistência, a coerência. De outro modo, os alunos não conseguiriam aprender, porque não haveria o que aprender. De uma hora para outra o professor não pode dizer que uma igualdade é o mesmo que uma desigualdade. 1 é 1 e 2 é 2. Noutro modelo, 1,0 é 1,0 e 2,0 é 2,0. 1 não pode virar 2. 1,0 não pode virar 2,0.

o leitor interessado naturalmente irá, posteriormente, buscar mais informações por conta própria, como você já fez no passado (e por isto conhece as diferenças entre GPL, software livre, freeware etc.) e daí aprenderá por si mesmo as diferenças mais detalhadas que existem entre os conceitos.

Não conto com isso. Eu posso ter feito, mas muito gente não faz, e nunca fará.

Uma sugestão: você pode divulgar aquele link que forneci, espalhá-lo nas redes sociais etc., para que mais pessoas se familiarizem com as diferenças.

Só não sigo a sugestão porque opto por não participar de redes sociais. Ando a divulgar essas ideias de outras formas.

[Sampayu]

São "modelos" da Ciência, convenções por si mesmas. A maior parte de sua analogia está demasiadamente elástica.

A nomeação de todas as coisas, começando por aquelas encontradas na natureza (tais como animais e plantas) também é convenção, isso é verdade. Mas são convenções incomparavelmente mais enraizadas do que aquelas dos "modelos" que a Ciência elabora e propõe. De tal modo que não convém chamar carro de avião e macaco de galinha.

O modelo que o professor de física de ensino médio usa não é o mesmo modelo usado no ensino superior. Dentro do modelo, o professor precisa manter a consistência, a coerência. De outro modo, os alunos não conseguiriam aprender, porque não haveria o que aprender. De uma hora para outra o professor não pode dizer que uma igualdade é o mesmo que uma desigualdade. 1 é 1 e 2 é 2. Noutro modelo, 1,0 é 1,0 e 2,0 é 2,0. 1 não pode virar 2. 1,0 não pode virar 2,0.

Na base binária 1 + 1 = 10 (e não faz sentido grafar 2,0), rs. Mas eu entendi o que você quis dizer. Como disse, são divergências de opinião. Eu procuro um meio-termo, tento preservar o formalismo indispensável e dispensar o formalismo dispensável. Mas o que é "dispensável" e o que é "indispensável" varia de acordo com as concepções de quem lê. Aquele usuário para quem o meu post se dirigiu entendeu a mensagem principal, embora realmente vá precisar ler mais caso queira compreender as diferenças entre freeware, open source etc., já que no meu texto elas ficaram confusas (antes de eu efetuar alguns ajustes).

Só não sigo a sugestão porque opto por não participar de redes sociais. Ando a divulgar essas ideias de outras formas.

Eu também não participo de redes sociais (Facebook, Twitter, LinkedIn etc.). Elas servem para as empresas mantenedoras dessas redes sociais coletarem dados nossos, traçarem nossos perfis comportamentais e sociais e venderem essas informações para as empresas parceiras que as financiam. Se bem que hoje em dia é praticamente impossível escapar disso (eu uso YouTube e smartphone com Android, por isto o Google já criou automaticamente uma conta pra mim no Google+ e várias pessoas que me conhecem já me adicionaram. É complicado...). Mas a gente faz o que pode...

[alexandre.mbm]

Na base binária 1 + 1 = 10 (e não faz sentido grafar 2,0), rs.

Mais modelos.

Mas eu entendi o que você quis dizer.

Ufa!

Eu também não participo de redes sociais (Facebook, Twitter, LinkedIn etc.). Elas servem para as empresas mantenedoras dessas redes sociais coletarem dados nossos, traçarem nossos perfis comportamentais e sociais e venderem essas informações para as empresas parceiras que as financiam. Se bem que hoje em dia é praticamente impossível escapar disso (eu uso YouTube e smartphone com Android, por isto o Google já criou automaticamente uma conta pra mim no Google+ e várias pessoas que me conhecem já me adicionaram. É complicado...). Mas a gente faz o que pode...

Essas suas motivações são muito importantes, mas eu também tenho outras.

[alevian]

Companheiros,

Muito interessante a discussão.

De fato, a utilização do openjdk poderia gerar uma batalha judicial.
Caberia até consultar na jurisprudência se algum banco já usou esse argumento - creio que não.

Não sou especialista em Direito, mas uma coisa é certa:o Código de Defesa do Consumidor não deixa dúvidas de que os fornecedores devem prestar informações claras, adequadas e precisas aos consumidores. E, ainda, tudo aquilo que limita o direito deve ser informado ostensivamente, em destaque. Especialmente no tocante à segurança.

Visitei agorinha os sites do BB, do Itaú e da CEF.
O da Caixa chega a ser surreal. Estão no tempo do XP!

Não me pareceram muito específicos, por vezes não citaram nem nome de empresas como Oracle/Sun.
Em algumas situações, como o da Corretora Itaú, nem chegam a citar possibilidade de uso do Linux, embora no banco do mesmo grupo exista essa possibilidade.

Por fim, não chegaram a dizer que o uso do programa "a" ou "b" poderia implicar na perda de meus recursos. Claro! São espertinhos, não querem perder clientes, ainda que sejam parte de uma minoriazinha.
Assim, penso que se está bom pra eles e pra mim enquanto tudo dá certo, devem responder se um dia algo der errado.

Ainda assim, parece mesmo complicada a escolha.

Se tiverem tempo, vejam as colocações neste blog de uma comunidade Slack sobre as últimas mudanças no OpenJDK e IcedTea :
http://alien.slackbook.org/blog/

Também não podemos esquecer do nosso compromisso com o software livre e aberto:

http://www.softwarepublico.gov.br/file/25045612/DocFISL.pdf
http://soujavalivre.blogspot.com.br/2014/03/festa-de-lancamento-do-java-8.html

Abraços.