Como o Java recebeu esse nome?

De: James Gosling
Data: 24 de Agosto de 2007 – 20:16:58
Para: Jonathan Schwartz
Assunto: Como o Java recebeu esse nome?
A história é a seguinte:
Nós precisávamos de um nome. Estávamos usando “oak” (que eu escolhi randomicamente), e embora o time tenha se apegado e ele, os advogados responsáveis pelo registro de marcas o descartaram. Tivemos muitos debates por email sobre nomes, mas nada era resolvido. Acabamos na estranha posição em que a única coisa que nos impedia de fazer o lançamento era o nome. Nosso líder de marketing conhecia alguém que era um “consultor de nomes” (eu não lembro o nome dele, mas ele era ótimo). Nós não podíamos pagar o preço nem tínhamos tempo para fazer um processo completo de criação de nome de produto. Ele concordou em fazer algo bem atípico, mas efetivo e rápido: ele atuou como um facilitador em uma reunião onde uma dúzia de nós nos trancamos em uma sala por uma tarde. Neste momento ele começou perguntando questões como “Como esta coisa faz vocês se sentirem?” (Animados!) “O que mais faz com que vocês se sintam assim?” (Café, Java!*). Chegamos a um quadro coberto de palavras aleatórias. Então, ele nos conduziu em um processo de ordenação onde finalizamos com um ranking de nomes. Acabamos com uma dúzia de nomes candidatos e os enviamos para os advogados: eles trabalharam na lista de cima para baixo até que chegaram a um nome que passou pela pesquisa deles. “Java” era o quarto nome na lista. O primeiro nome era “Silk”, que eu odiei, mas todos os outros gostaram. Meu favorito era “Lyric”, o terceiro na lista, mas ele não passou pelo teste dos advogados. Eu não lembro quais eram os outros candidatos.
Então, quem deu o nome Java? Uma reunião organizada pelo marketing, o consultor que a organizou, e um monte de nós gritando várias palavras aleatórias. Eu honestamente não tenho certeza absoluta de quem disse “Java” primeiro, mas acredito que tenha sido Mark Opperman.
Com certeza não foi nenhuma mente brilhante de marketing usando um processo coerente e bem pensado.
* “Java” é uma gíria norte-americana para café (NT).

How to validate URL in Java

A short example to show the use of apache.commons.validator.UrlValidator class to validate an URL in Java.

import org.apache.commons.validator.UrlValidator;
 
public class ValidateUrlExample{
 
	public static void main(String[] args) {
 
	    UrlValidator urlValidator = new UrlValidator();
 
	    // valid URL
	    if (urlValidator.isValid("http://www.ziben.com.br")) {
	       System.out.println("url is valid");
	    } else {
	       System.out.println("url is invalid");
	    }
 
	    // invalid URL
	    if (urlValidator.isValid("http://invalidURL^$&%$&^")) {
	        System.out.println("url is valid");
	    } else {
	        System.out.println("url is invalid");
	    }
 
	}
}

Output

url is valid
url is invalid

Reference

  1. http://commons.apache.org/validator/apidocs/org/apache/commons/validator/UrlValidator.html

As novidades do kernel 2.6.36

No dia 20 de outubro de 2010, o finlandês agora cidadão americano Linus Torvalds apresentou ao mundo a versão mais recente de seu kernel livre, o Linux 2.6.36. Com o codinome Flesh-Eating Bats with Fangs em homenagem a um morcego que recentemente invadiu a residência dos Torvalds — alguém comentou no blog de Linus que “o Batman finalmente invadiu a casa do Pinguim” — esta nova versão do Linux foi completada em 80 dias, precisamente a duração média dos últimos lançamentos de versões estáveis do kernel. Porém, com uma versão -rc a mais — recentemente, essas versões só chegavam até -rc7, mas alcançaram -rc8 desta vez — a versão estável “pareceu demorar mais do que de costume”, alegaram alguns desenvolvedores.

O kernel encolheu??? Que bom!

Pela primeira vez nos últimos vários anos, uma nova versão do kernel Linux traz menos linhas de código do que a anterior: 13,49 milhões, contra 13,54 milhões na versão 2.6.35 e 13,32 milhões no Linux 2.6.34. Curiosamente, o número de arquivos aumentou de 33,3 mil na versão anterior para 34,3 mil no Flesh-Eating Bats. Além disso, pela terceira vez consecutiva o número de commits que compõem o kernel ficou abaixo dos 10 mil, mais precisamente em 9501.

A redução no tamanho do kernel se explica pelo admirável trabalho de faxina que vem sendo feito na base de código em constante evolução. Os avanços na remoção da BKL (Big Kernel Lock), por exemplo, foram significativos nesta versão.

Vamos às novidades!

AppArmor, finalmente

AppArmor é um sistema de “controle de acesso obrigatório” (Mandatory Access Control ou simplesmente MAC). Desenvolvido pela empresa Immunix nos idos de 1998, ele foi mantido pela Novell — que adquiriu a Immunix — de 2005 a 2007, quando a fabricante do SUSE Linux Enterprise dispensou seus desenvolvedores.

O AppArmor é ativado por padrão em diversas distribuições, sendo os principais exemplos Ubuntu e SUSE Linux Enterprise (Desktop e Server). Incluído no kernel, ele passa a fazer companhia aos demais residentes SELinuxTOMOYOSMACK.

Desktops mais rápidos, mesmo sob pressão

Na área dos desktops, uma série de patches tornam o escalonador mais competente com relação à redução da latência máxima dos processos — nenhuma relação com os patches de Con Kolivas. Juntamente com as novas workqueues implementadas no kernel, o uso de múltiplas tarefas concorrentes num único sistema poderá ser significativamente mais rápido. Por último, um conjunto de patches finalmente dá alento aos pobres coitados que possuem dispositivos de bloco muito lentos. A partir do kernel 2.6.36, os sistemas conectados a esses dispositivos não mais ficarão praticamente incapacitados de reagir quando seus dispositivos — mesmo os USB — demorarem a responder.

Vídeo

Se você possui uma GPU integrada a seu processador Core i3 ou i5, poderá utilizar todos os benefícios do suporte ao Intel Intelligent Power Sharing, recurso presente nesses hardwares que permite um melhor uso — compartilhado, como sempre deveria ser — entre esses dois componentes do “pacote” presente na pastilha de silício. Os benefícios são uma espécie de “overclock” automático da GPU quando a CPU não está a todo vapor, ou então CPU e GPU mais frias e economia de energia quando não estiverem ambas sendo usadas ao máximo.

Ao trabalhar com GPUs AMD Radeon, o Linux enfim se tornou capaz de ler os sensores de temperatura dessas GPUs, entre outras novidades.

Já no campo da concorrente Nvidia, o driver KMS Nouveau passa a incluir suporte — embora ainda básico — às GPUs Fermi presentes na recente série GeForce 400.

Controle remoto via infravermelho

O uso de dispositivos infravermelhos no Linux é, historicamente, trabalhoso. Porém, isto finalmente está mudando. Com os avanços iniciados no Linux 2.6.35, o kernel agora oferece interfaces utilizáveis pelo utilitário LIRC, que por sua vez faz a interface com transmissores e receptores infravermelhos. Com isso, os drivers, antes mantidos no espaço do usuário junto ao próprio LIRC, estão sendo migrados, pouco a pouco, para dentro do kernel.

Compressão de memória mudou de nome novamente

Compcache? Não, o nome mudou para Ramzswap. E quando finalmente foi incorporado ao kernel 2.6.36, o dispositivos de blocos compactado na memória RAM recebeu um novo nome: Zram.

Para usar o Zram, basta ativá-lo nos drivers staging e carregá-lo (chama-se zram). Com isso, cria-se ao menos um dispositivo de blocos compactado, em /dev/zram0. É possível encomendar mais dispositivos por meio de uma opção de carregamento do módulo zram. Para definir seu tamanho, não é mais necessário um utilitário, pois seus controles mudaram dos ioctls para o sysfs. O resultado: basta usar echo 100000 > /sys/block/zram0/size para definir um tamanho de 100 MB para o dispositivo zram0.

Nota: em testes na minha própria máquina, este método não funcionou, pois o sysfs não permitiu a gravação de novos dados no arquivo /sys/block/zram0/size.

Matador mais competente

Quando seu sistema utiliza toda a memória RAM disponível, ele passa a recorrer ao espaço de swap. Quando acaba o swap… alguém (algum processo, é claro!) precisa morrer. O matador de processos se chama OOM (out-of-memory) Killer, e não é sempre tão inteligente. Porém, seus desenvolvedores perceberam que é sempre bom ter um pouco mais de inteligência, mesmo que seu trabalho seja apenas apertar um gatilho. O OOM Killer agora é capaz de tomar melhores decisões a respeito de quais processos matar a fim de liberar a tão valiosa memória.

Novos processadores, nova arquitetura

Uma nova arquitetura de CPU, que ainda nem existe na prática, chamada Tilera, já conta com suporte oficial do Linux. É mais um caso que demonstra a rapidez de evolução e adoção de novas tecnologias típica do Software Livre e, em particular, do kernel Linux. Se a Tilera entregar o que promete, poderemos ter um salto interessante no poder computacional disponível em máquinas comuns.

Já nas arquiteturas tradicionalmente suportadas, o Linux agora funciona com CPUs Tegra da Nvidia, baseadas em ARM.

Novas opções de compilação

Os novos alvos de compilação oldnoconfiglistnewconfigalldefconfigsavedefconfig já foram usados pelos desenvolvedores para eliminar mais de 200 mil linhas de código referentes a arquivos de configuração padrão para as várias arquiteturas suportadas pelo Linux. De certa forma, é como se eles pudessem agora usar um diff dos arquivos de configuração padrão, em vez de uma cópia completa do arquivo de configuração padrão somada às configurações padrão daquela arquitetura específica. Viu como a redução do código foi boa? 🙂

Virtualização

KVM e Xen são grandes concorrentes, mas cada vez mais semelhantes. Os desenvolvedores do KVM acrescentaram alguns recursos que permitem uma espécie de suporte reduzido à execução do Linux como Dom0. Seria este o começo da união entre os dois principais tipos de hypervisors do kernel Linux? Resultados das atuais discussões na LKML poderão ser vistos em uma versão bem próxima do kernel.

Fanotify

A tão prometida e desejada varredura de arquivos sob demanda — imagine isso num sistema antivírus — está mais próxima: o novo sistema Fanotify entrou, embora “de leve”, no kernel. No entanto, vem desativado por padrão em virtude de discordâncias quanto à sua API. A tendência é que o Fanotify substitua as duas “gambiarras” usadas até o momento (sem grande sucesso) para esse mesmo propósito, fsnotifydnotify. O Fanotify é uma estrutura do subsistema de sistemas de arquivos capaz de enviar mensagens ao espaço de usuário (por exemplo, a um software antivírus) informando sobre a abertura, alteração ou fechamento de arquivos. Assim que ela ficar pronta, podemos esperar que seja muito usada em diversos tipos de programas.

Sistemas de arquivos

Quem acessa compartilhamentos remotos via NFS já testemunhou, a partir do kernel 2.6.30, os benefícios do cache local de sistemas de arquivos remotos. A boa notícia: se você usa CIFS para isso, finalmente sua hora chegou. Sistemas de arquivos CIFS agora já têm suporte a essa estrutura, chamada FS-Cache.

No campo do já antigo sistema de arquivos Ext3, a onda retrô levou os desenvolvedores a tornar padrão, novamente, a opção de montagem data=ordered. Ela oferece maior segurança e menor desempenho do que o “antigo novo padrão”, data=writeback.

De forma genérica, o XFS também recebeu vários patches destinados a “melhorar seu desempenho em vários trechos”.

A redundância de subsistemas para lidar com RAID também está finalmente diminuindo. Enquanto o Btrfs recebeu grandes trechos de código do subsistema MD para acrescentar ao futuro sistema de arquivos padrão recursos de RAID 6, o subsistema DM (device mapper) começa a ceder seu código de RAID 5 para outros trechos, de forma a permitir, no futuro, que o utilitário dmraid gerencie também implementações de RAID em drivers de controladoras etc.

Quem usa discos SSD agora também terá mais uma ajuda do subsistema DM, que ganha suporte ao comando discard, capaz de informar que determinada área de dados está disponível — economizando assim um novo ciclo de leitura em todos os blocos que a compõem e estendendo a vida útil dos dispositivos. Tudo isso depende, todavia, da existência de suporte ao comando discard por parte do disco e de sua respectiva controladora.

KGDB + KDB + KMS

Esta sopa de letrinhas tem um significado especial para os desenvolvedores do kernel. O depurador do kernel, KDB (kernel debugger), agora trabalha em parceria com o driver Intel KMS. Isso significa que, na presença de uma GPU Intel que use esse driver, o KDB pode ser acessado a qualquer momento pressionando as teclas SysRqG(confira o resultado neste vídeo).

Futuro

Está em andamento uma iniciativa para aumentar a escalabilidade do VFS (Virtual Filesystem Switch), que já mostrou frutos nesta atual versão do Linux. Espera-se que haja ainda mais novidades no kernel 2.6.37. Da mesma forma, os grandes e contínuos avanços na remoção da BKL (Big Kernel Lock) sinalizam que o kernel inteiro deve ganhar mais desempenho, tanto na versão 2.6.36 quanto nas próximas.

Pode-se esperar também que a integração do KDB, neste momento restrita ao driver KMS Intel, seja incorporada aos concorrentes Nouveau e Radeon.

Este foi o último lançamento de kernel estável em 2010. A versão 2.6.37 do kernel Linux deve ser lançada em janeiro de 2011.

Post original aqui.

Hole in Linux kernel provides root rights

A flaw in the implementation of the Reliable Datagram Sockets protocol (RDS) in the Linux kernel can be exploited to gain root (also known as superuser) rights or permissions on a victim’s system. Attackers can exploit the hole to get complete control remotely once they have broken into the system. Dan Rosenberg, who discovered the vulnerability, has published an exploit for demonstration purposes; in a test conducted by The H’s associates at heise Security on Ubuntu 10.04 (64-bit), it opened a root shell.

Kernel versions 2.6.30 to 2.6.36-rc8 are said to be affected. Linux developers have already provided a patch, in the Git repository, that solves the problem. Distributors will probably be publishing new kernel versions soon. As a workaround, Rosenberg recommends preventing the kernel module from loading: echo “alias net-pf-21 off” > /etc/modprobe.d/disable-rds (as root). Most systems will not be affected as they do not use the protocol anyway.

Rosenberg says the problem came about because the kernel functions in the RDS protocol do not correctly check the addresses given when data are copied from kernel memory and user memory. As a result, local users can indicate a basic address within the kernel for a socket structure. Code can then be written into kernel memory and launched with kernel rights when certain sockets are called.

Just a few days ago, a hole in the GNU-C library’s loader was made public that also allows attackers to expand their rights on the system.

Google dá resposta nerd a crítica de Steve Jobs ao Android

Uma das principais características alardeadas pelo Google para o Android é sua plataforma aberta e baseada no Linux, facilitando aos programadores a criação de aplicativos. No entanto, Steve Jobs – executivo-chefe da Apple – fez críticas à mesma em uma teleconferência realizada nesta semana.

Andy Rubin, chefe da divisão Android, inaugurou seu perfil no Twitter em 18 de outubro com uma resposta à crítica de Jobs. Sua mensagem foi enviada em forma de uma sequência de comandos que equivalem à cópia do Android para sua máquina Linux e sua compilação na sequência, deixando-o prontinho para rodar.

Para quem ficou curioso, veja a sequência citada por Rubin:

mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make