Recebi o seguinte comentário no meu post "6 meses de Arch Linux" e achei interessante alguns pontos colocados:
"O problema do linux é esse, cda 6 meses tem q mudar, pq? pq são tts distros q eles não conseguem ficar s fuçar e acaba saindo outra. A gente se ferra pq faz uma atualização q não da certo, vc precisa reinstalar o sistema, q na verdade não reisntala coisa nenhuma e vc perde td. Pior de td é q nunca uma distro é sequência da anterior. Aí é q a gente dança. Adorei o linux, usei durante 3 anos, mas sempre mudando, comprando cd e jogando pq não dava certo. Me desgostei de vez c o biglinux 4, pra comiçar uma cópia do xp, clone ou imitação, sei lá, pior msm é q mouse não funciona, da um trabalho pra fazer funcionar, depois de td pronto, td quase funcionado, faz uma atualização e pronto, mouse não funciona mais. Daí cansei, né? To c o xp, o xpsp3 ta bom, como eu já disse, parece o biglinux 4.0, única coisa chata é q ele pega uns vírus de vez em qd, mas daí a gente mata."
Olha isso não é mais tão verdade hoje em dia, emho.
Muitas distros como Fedora, (K)Ubuntu, etc.. oferecem a opção de você fazer o upgrade para uma versão mais nova. Sim, sei que isso nem sempre da certo (já deu bastante errado comigo :P).
Mas você também não precisa fazer upgrade para novas versões, ainda mais se for em um ambiente de produção (ou um PC de trabalho), aonde você não *precisa* de nenhuma funcionalidade da nova versão, talvez como um novo kernel ou novas versões de ferramentas que você usa.
Por exemplo, hoje um release normal do (K)Ubuntu tem suporte a updates de seus pacotes por até 1 ano e meio e as versões LTS tem suporte de 3 anos. O Fedora se não me engano é de 1 ano o suporte.
A diferença é que estas atualizações são somente fixes de problemas de segurança e bugs, nunca adição de novas funcionalidades (pelo menos no caso do (K)Ubuntu, não tenho certeza do Fedora pois ele é mais bleeding edge).
Uma dica que eu posso dar e é o que eu faço é utilizar seu /home em uma partição separada, pois caso o upgrade mande seu sistema para o vinagre, o *seus* dados, pelo menos os pessoais, estarão a salvo.
(Mas é claro que a política de backup pelo menos mensal - que ninguém - seria uma boa também... sabe deus quando seu HD vai para o brejo?)
Temos ainda outra classe de distros com o Arch Linux e o Gentoo que são chamadas de "Rolling Distros", ou seja distros que sempre estão atualizadas. Depois de instaladas uma única vez, se você sempre manter ela atualizada (pelo pacman no Arch e pelo portage no Gentoo), sempre terá uma instalação exatamente *igual* a qualquer nova versão que lancem.
Isso é somente uma questão de gosto e gerenciamento de pacotes... um exemplo que posso citar é o do kernel no (K)Ubuntu e no Arch.
No (K)Ubuntu 8.04, o kernel vai ser sempre o mesmo, o 2.6.24 (a menos que você pegue e compile o seu na mão... mas ai estamos roubando :P), isso durante os 3 anos (pois o 8.04 é um LTS, Long Time Suport, se não seria por 1 ano e meio), não importando quantas novas versões do kernel saiam nesse período. Quando sair o (K)Ubuntu 8.10 com kernel 2.6.27, quem quiser ficar com o 8.04 vai continuar usando o 2.6.24 e ponto.
Já no Arch, novas versões do kernel são rapidamente testadas inicialmente pelos desenvolvedores, colocadas no repositório testing e em pouco tempo ja estão no repositório principal para quem quiser usar. Assim que sair um novo CD de instalação do Arch ele estará com este mesmo novo kernel! (Se não me engano, ja teve até um caso em que o kernel do CD era mais antigo que o do repositório mesmo, ja no dia da instalação ou 1 ou 2 dias depois!)
Veja bem que uma "rolling distro" não precisa ser algo "bleeding edge".
No Arch Linux isso acaba acontecendo (mesmo sem usar o testing e outros...), mas no Gentoo por exemplo, caso você use a linha stable dele (como todos os sistemas de produção e ambientes de trabalho deveriam...) você não necessariamente tem os softwares mais atuais, mas quando um novo CD de instalação ou o que seja for lançado, você terá o mesmo sistema de quem utilizar este CD.
Por exemplo, hoje (26/10/2006) temos no Arch Linux o kernel 2.6.27.1 no repositório estável - Core - porém ja marcado como "obsoleto" por que já estamos na versão 2.6.27.4.
Porém no Gentoo a coisa é um pouco mais enrolada, como tudo é compilado pelo usuário lá, você pode pegar qualquer versão que queira, porém somente algumas são marcadas como estáveis....
Vamos lá... o pacote "vanilla-sources" que é o kernel como ele veio ao mundo, ou seja, é o kernel do kernel.org sem nenhum patch, temos as seguintes versões estáveis para x86 E AMD64:
2.6.19.7, 2.6.23.9, 2.6.23.17, 2.6.24.3, 2.6.24.4, 2.6.24.7 e a 2.6.25.9 que é a mais nova que esta marcada estável para os dois. Se formos ver somente para x86 ainda temos 2.6.25.11, 2.6.25.14 e 2.6.25.17.
Não me pergunte o por que da 2.6.25.14 e a 2.6.25.17 serem estáveis e as 2.6.25.15, 2.6.25.16 não. Coisa deles, testes deles. Mas temos todas as possíveis versões, até a 2.6.27.4 la, porém marcadas como instáveis. Pode usar? Claro que pode... mas eles tão dizendo que não colocam a mão no fogo por elas (nem nas outras eles colocam provavelmente :P).
Se você for ver então a "git-sources" (que representa a arvore de desenvolvimento do kernel) pode até pegar o kernel 2.6.28_rc1 (release candidate 1 da nova versão, a merge windows acabou de ser fechada!! É pedir para ter um kernel panic), ou mesmo o 2.6.28_rc1-git1 (o rc1 + as ultimas mudanças que fizeram de ontem pra hoje!). Claro que tudo isso é marcado como instável.
E por fim temos a "gentoo-sources" que trata de uma kernel com diversos patches aplicados pela equipe do gentoo, onde a mais estável para amd64 é o 2.6.25-r7 e para x86 é o 2.6.25-r8 (mesmo tendo ja o 2.6.27-r1)... apenas prestar atenção que esse -rX é relativo aos patches aplicados pela equipe do gentoo sobre o kernel, não confundir com o -rcX do kernel.
Voltando ao comentário... outro ponto é que concordo que existem muitas distros. Isso pode ser algo bom e ruim, mas realmente alguem novo ou que não tenha ainda escolhido uma (ou umas :P) que gosta mais, realmente fica bem perdido.
Acho que cada uma tem seus prós e contras, seria bom se fosse possível juntar todos os prós e remover todos os contras, mas infelizmente (ou seria felizmente?) cada distro tem sua filosofia de desenvolvimento, seu público alvo (Por exemplo... as vezes me sinto entediado no (K)Ubuntu. Ou então tente dar um Gentoo para quem nunca usou Linux na vida...).
E o principal temos as pessoas que colaboram e que fazem isso por que gostam de fazer e gostam do "jeito de ser" de uma determinada distro... não podemos força-las a desenvolver de outra maneira, para outro público alvo... apenas vai irrita-las ou chateá-las e não teremos mais desenvolvimento algum =/
(E pela filosofia do Software Livre... não deveríamos querer obrigar ninguém a fazer nada... aonde ao extremo, podemos fazer nós mesmo algo que não gostamos do jeito que está sendo feito :)
Sobre o BigLinux 4, eu particularmente nunca utilizei-o. Mas essa "tática" de ter um visual parecido com o XP é para ajudar o pessoal que vem do Windows, para tornar menos traumático :P.
Se todos usassem Linux/Unix desde criancinha, não seria necessário... mas crescemos usando windows 95, 98, 2000, XP, Vista, etc... (ok... eu tmb usei DOS e 3.11 xD) então ou a pessoa tem um estalo divino para usar Linux ou então a transição tem que ser amigável.
Eu acho a tela preta e a compilação de programas um charme no Linux... vai ver eu sou biruta de pedra.
Mas um usuário normal, minha mãe, minha irmã, minha vó, meu tio... aqueles que querem usar o Firefox (há... ja escondi o IE a muito tempo do computador deles :P) e ver e-mails e YouTube, querem se sentir "seguros"... do tipo "sei onde estou e sei o que estou fazendo".
Se o BigLinux consegue ser uma porta de entrada para muitas pessoas ao Software Livre eu dou meus parabéns a ele!!!
Por que se for para copiar o "visual do XP", muita gente ja copiou muita coisa do MAC e eu não uso MAC hoje por isso (eu não uso MAC porque eu sou pobre mesmo :P).
O Windows utiliza o sistema de gerenciamento de memória do BSD e não é por isso que eu utilizo o BSD (até porque essa joça não faz boot no meu notebook... -_-').
Eu particularmente, evito usar windows, não porque odeio a Microsoft, não acho que o Bill Gates é o filho do capeta e que tem a instituição dele lá que ajuda (e coloca ajuda nisso... o cara tem quase nada de dinheiro para doar) somente como faixada...
Eu uso Linux, por que GOSTO do Linux. Acho FODA o conceito de comunidade. Acho FODA PRA CARALHO o desenvolvimento colaborativo onde cada um ajuda como quer. Acho super legal a idéia do Software Livre, o conhecimento pertence ao mundo, yeah!
Mas se precisar, uso Windows de boa. (Afinal eu quero jogar também, sem ter que usar wine/cedega/etc... :P)
Não tenho problema no Windows com vírus nem com suas falhas de segurança. 99% dos vírus/worms/etc... com algumas precauções pode-se evitar facilmente. Falhas de segurança todos tem. O Linux (kernel) e os programas que utilizamos todos os dias... vixe, tem várias... eles corrigem rápido na maioria das vezes, mas isso não diz que estejam seguros... quantas pessoas não atualizam seus pacotes? Mesmo com as facilidades de hoje em dia? O mesmo vale para o Windows Update...
Infelizmente a segurança rompe no elo mais fraco... o usuário =]
(Já chegamos até em papo de segurança... acho que podemos ir parando por aqui :)
É isso... eu como disse, vou continuar utilizando meu Linux aqui e estou feliz com ele (mesmo sabendo que a minha natureza de nômade de distro, me fará mudar em breve :P).
Olha... o que eu ouço falar de nego reinstalado Windows de 6 em 6 meses... seja por que pegou vírus, ou por causa da famosa DLL Hell, ou por que o sistema travou e ferrou alguma coisa, ou então por que o registro foi para o saco, etc... (muita coisa... 99% culpa do usuário =).
Se for necessário, eu prefiro reinstalar o Linux de 6 em 6 meses... =]
domingo, 26 de outubro de 2008
sábado, 25 de outubro de 2008
True Blood
Vou falar da ultima série que comecei a assistir e está ainda no sétimo episodio de sua primeira temporada (mas domingo temos o 8 \o/).
Primeiro... se não fosse minha namorada eu nunca ia saber da existência dessa série :P
Então... a série basicamente é sobre vampiros... num mundo como o nosso, mas onde vampiros existem publicamente. Se são aceitos ou não... é controverso, alguns personagens são a favor, outros contra... tem até lei a favor dos vampiros a ser votada (x-man? lei a favor dos mutantes? alguem?).
Bem, uns japas criaram ai uma bebida (TruBlood, há!) que seria um sangue sintético, assim permitindo que os vampiros possam se alimentar disso ao invés de... sabe... pessoas. Mas é claro que coisas naturais são bem melhores ;)
Enfim, os personagens principais são:
Sookie Stackhouse: A protagonista da série. Ela tem uma habilidade muito peculiar, que a deixa muitas vezes desconfortável com outros humanos... e por isso ela tem uma quedinha por vampiros :P
Por causa desta habilidade muita gente acha que ela tem problemas. Ela vive com sua avó e seu irmão...
Jason Stackhouse: Irmão de Sookie, é o mais putão que eu ja vi. OMFG sério. Ele tem sérios problemas com vampiros, odeia todos eles. É o muleque irresponsável e que sempre faz merda =D
Tara Thornton: Amiga de infância de Sookie e Jason. IMHO, essa mulher ta com TPM 24x7 :P. Tem uma quedinha (mentira, é uma quedona mesmo) por Jason e fará de tudo para protege-lo. Tem também um sério problema com sua mãe, que é alcoólatra.
Sam Merlotte: Dono do bar onde Sookie e Tara trabalham. É um personagem muito misterioso... muito pouco é falado sobre sua história/passado. Tem uma queda (para não dizer desmoronamento) por Sookie.
Bill Compton: Esse é O CARA (ou melhor, O VAMPIRO). É o "vampiro do bem"... ou que tenta se integrar a sociedade, mesmo que alguns outros vampiros sejam contra isso e prefiram continuar do mesmo modo que sempre foi.
Ele é caralisticamente foda... e ainda da uns pegas na Sookie.
Lafayette Reynolds: Primo de Tara e trabalha na cozinha do bar de Sam. Ele é Gay ou Bi, não sei... mas é engraçado pra caraleo.
Bem, esses são os personagens principais apresentados até agora =]
A série no geral é bem legal... não posso dizer que seja perfeita que nem Lost, mas ja to querendo desesperadamente o oitavo episodio :P
No início eu achei ela meio +-, legal e tal, mas nada de demais... mas do 5o pro 7o, a coisa ficou TENSA!!!! =D
Uma coisa... eu não sei o que raios tem nessa cidade, mas que ta todo mundo no cio, 20% de cada episodio é sexo. Não que eu esteja reclamando... mas esse pessoal ta demais... da-lhe V-Juice...
E para terminar a intro da série (que eu achei muito boa), e a música tema é a Bad Things - Jace Everett:
Primeiro... se não fosse minha namorada eu nunca ia saber da existência dessa série :P
Então... a série basicamente é sobre vampiros... num mundo como o nosso, mas onde vampiros existem publicamente. Se são aceitos ou não... é controverso, alguns personagens são a favor, outros contra... tem até lei a favor dos vampiros a ser votada (x-man? lei a favor dos mutantes? alguem?).
Bem, uns japas criaram ai uma bebida (TruBlood, há!) que seria um sangue sintético, assim permitindo que os vampiros possam se alimentar disso ao invés de... sabe... pessoas. Mas é claro que coisas naturais são bem melhores ;)
Enfim, os personagens principais são:
Sookie Stackhouse: A protagonista da série. Ela tem uma habilidade muito peculiar, que a deixa muitas vezes desconfortável com outros humanos... e por isso ela tem uma quedinha por vampiros :P
Por causa desta habilidade muita gente acha que ela tem problemas. Ela vive com sua avó e seu irmão...
Jason Stackhouse: Irmão de Sookie, é o mais putão que eu ja vi. OMFG sério. Ele tem sérios problemas com vampiros, odeia todos eles. É o muleque irresponsável e que sempre faz merda =D
Tara Thornton: Amiga de infância de Sookie e Jason. IMHO, essa mulher ta com TPM 24x7 :P. Tem uma quedinha (mentira, é uma quedona mesmo) por Jason e fará de tudo para protege-lo. Tem também um sério problema com sua mãe, que é alcoólatra.
Sam Merlotte: Dono do bar onde Sookie e Tara trabalham. É um personagem muito misterioso... muito pouco é falado sobre sua história/passado. Tem uma queda (para não dizer desmoronamento) por Sookie.
Bill Compton: Esse é O CARA (ou melhor, O VAMPIRO). É o "vampiro do bem"... ou que tenta se integrar a sociedade, mesmo que alguns outros vampiros sejam contra isso e prefiram continuar do mesmo modo que sempre foi.
Ele é caralisticamente foda... e ainda da uns pegas na Sookie.
Lafayette Reynolds: Primo de Tara e trabalha na cozinha do bar de Sam. Ele é Gay ou Bi, não sei... mas é engraçado pra caraleo.
Bem, esses são os personagens principais apresentados até agora =]
A série no geral é bem legal... não posso dizer que seja perfeita que nem Lost, mas ja to querendo desesperadamente o oitavo episodio :P
No início eu achei ela meio +-, legal e tal, mas nada de demais... mas do 5o pro 7o, a coisa ficou TENSA!!!! =D
Uma coisa... eu não sei o que raios tem nessa cidade, mas que ta todo mundo no cio, 20% de cada episodio é sexo. Não que eu esteja reclamando... mas esse pessoal ta demais... da-lhe V-Juice...
E para terminar a intro da série (que eu achei muito boa), e a música tema é a Bad Things - Jace Everett:
quinta-feira, 23 de outubro de 2008
Alguns filmes...
Que vi neste mês:
Speed Racer:
Legal... sim, apenas isso. Nada de demais. Não me fez sentir *aquela* saudade de quando eu era menor. Ficou muito F-Zero-like... não que seja ruim... mas foi apenas isso.
Os personagens estão muito bem representados, com destaque para o Pops, emho =D
O Corredor X, poderia ter ficado *muuuuito* mais legal... =/
Mandando Bala:
É distribuição de balas (e cenouras) o filme inteiro e o "heroi" é melhor que o MacGayver... ou seja: ÓTIMO FILME!
Sério, muito bom mesmo =D
O Vidente:
O plot até que é legal... mas o mais maneiro mesmo é como o "poder" do protagonista é mostrado, ficou muito foda!!! =D
Destaque para quando ele faz uma BFS dentro do navio! :P
Super-herois, a Liga da Injustiça:
Fato: não tem história (novidade...). Mas é muito divertido por todas as sátiras aos outros filmes =]
Corrida Mortal:
POOOHA!!!!!!!!!! MUITO BOOOOOOOOOM!!!
Me amarrei nesse filme!!! =D
Quero achar um jogo de PC nesse estilo ASAP! :P
Speed Racer:
Legal... sim, apenas isso. Nada de demais. Não me fez sentir *aquela* saudade de quando eu era menor. Ficou muito F-Zero-like... não que seja ruim... mas foi apenas isso.
Os personagens estão muito bem representados, com destaque para o Pops, emho =D
O Corredor X, poderia ter ficado *muuuuito* mais legal... =/
Mandando Bala:
É distribuição de balas (e cenouras) o filme inteiro e o "heroi" é melhor que o MacGayver... ou seja: ÓTIMO FILME!
Sério, muito bom mesmo =D
O Vidente:
O plot até que é legal... mas o mais maneiro mesmo é como o "poder" do protagonista é mostrado, ficou muito foda!!! =D
Destaque para quando ele faz uma BFS dentro do navio! :P
Super-herois, a Liga da Injustiça:
Fato: não tem história (novidade...). Mas é muito divertido por todas as sátiras aos outros filmes =]
Corrida Mortal:
POOOHA!!!!!!!!!! MUITO BOOOOOOOOOM!!!
Me amarrei nesse filme!!! =D
Quero achar um jogo de PC nesse estilo ASAP! :P
quarta-feira, 15 de outubro de 2008
O transito no rio...
... insuportável. Ou pelo menos na Zona Oeste...
2+ hrs para fazer Fundão -> Barra, algo que pode ser feito em 30 minutos com transito bom ou 1 hr no máximo em horário de engarrafamento (de manhã por exemplo).
2+ hrs para fazer Fundão -> Barra, algo que pode ser feito em 30 minutos com transito bom ou 1 hr no máximo em horário de engarrafamento (de manhã por exemplo).
Linux 2.6.27.1
Saiu uma nova versão do kernel, 2.6.27.1, com apenas um bugfix.
Este bugfix desabilita (e marca como broken) o CONFIG_DYNAMIC_FTRACE ("enable/disable ftrace tracepoints dynamically"), pois acredita-se que esta opção esteja causando uma corrupção de memória quando o módulo é descarregado e talvez este problema esteja relacionado com os recentes problemas de placas e1000.
Quem tem a 2.6.27 não precisa atualizar, pode somente desabilitar o DYNAMIC_FTRACE no seu .config e recompilar o kernel, pois como dito esta é a única mudança.
Este bugfix desabilita (e marca como broken) o CONFIG_DYNAMIC_FTRACE ("enable/disable ftrace tracepoints dynamically"), pois acredita-se que esta opção esteja causando uma corrupção de memória quando o módulo é descarregado e talvez este problema esteja relacionado com os recentes problemas de placas e1000.
Quem tem a 2.6.27 não precisa atualizar, pode somente desabilitar o DYNAMIC_FTRACE no seu .config e recompilar o kernel, pois como dito esta é a única mudança.
quinta-feira, 9 de outubro de 2008
O que esperar do Linux 2.6.27
O Linux 2.6.27 já esta em seu rc9, e em breve deverá acabou de ser lançado.
Mesmo o bug das placas de rede e1000e não tendo sido corrigido, o kernel conta com uma série de fixes que impedem que seja causado algum dano ao hardware.
Anyway, vamos dar uma olhada no quepodemos esperar desta temos nesta nova versão do kernel...
- Lockless page cache:
A "page cache" é o local onde o kernel deixa em memória uma cópia de um arquivo em disco, para evitar I/O.
Existia um lock para evitar problemas em sistemas com múltiplos CPUs, logo quando diferentes CPUs tentavam acessar arquivos diferentes não tínhamos problemas, porém quando dois CPUs tentavam acessar um mesmo arquivo (uma shared library do sistema por exemplo), somente um poderia ler a cada vez. Agora, graças a algumas novas regras que definem como a "page cache" é utilizada e pela utilização de RCU, será possível ler a "page cache" sem ser necessário fazer o lock.
Porém esta melhora só será observada em sistemas com muitas CPUs.
Links relacionados:
LWN: Toward better direct I/O scalability (http://lwn.net/Articles/275808/)
LWN: The lockless page cache (http://lwn.net/Articles/291826/)
WIKI: RCU (http://en.wikipedia.org/wiki/Read-copy-update)
- Lockless get_user_pages():
A função get_user_pages() é utilizada em operações de I/O diretas para travar o espaço de memória que será transferido.
Entretanto é uma função complexa e que utilizada semáforos e locks, que causavam problemas de escalabilidade quando se tinha diversos processos utilizando está função em uma mesma área de memória.
No kernel 2.6.27 uma nova função get_user_pages_fast() foi introduzida, a qual faz a mesma operação que a get_user_pages() porem determinadas operações foram simplificadas de modo que não é necessário obter o semáforo nem o lock. Alguns testes registraram uma melhora de 10% em um sistema quad-core com um banco de dados IBM DB2 com um workload OLTP.
Links relacionados:
WIKI: OLPT (http://en.wikipedia.org/wiki/Online_transaction_processing)
- Ext4: Delayed Allocation:
Neste versão foi adicionado ao sistema de arquivos ext4, um dos mais importantes recursos planejados a "Delayed Allocation" (alocação tardia, conhecida também como Allocate-on-flush).
Este recurso não altera a estrutura do disco, mas melhora a velocidade em diversas situações.
Uma breve explicação de como funciona: Quando uma aplicação quer escrever algo em disco, os dados não são escritos imediatamente, mas são colocados em uma área de memória RAM por algum tempo. Mas independente de ser escrita ou não imediatamente, o sistema de arquivos aloca as estruturas necessárias em disco na hora. A alocação tardia consiste em não alocar estas estruturas para os dados que estão cacheados na RAM, ela apenas atualiza a estrutura que indica quanto espaço livre em disco ainda temos, quando é feita uma operação de escrita. Os blocos e estruturas no disco são somente alocados quando os dados são realmente escritos.
Esta técnica é utilizada por outros sistemas de arquivos como o XFS, Btrfs, ZFS e o Reiser4 e apresenta um notável ganho de velocidade e também resulta em decisões melhores para a alocação dos blocos, pois neste momento o sistema de arquivos ja conhece tudo que deverá escrever.
Links relacionados:
WIKI: EXT4 (http://en.wikipedia.org/wiki/Ext4)
WIKI: Allocate-on-flush (http://en.wikipedia.org/wiki/Allocate-on-flush)
WIKI: Sistema de Arquivos (http://en.wikipedia.org/wiki/Filesystem)
WIKI: XFS (http://en.wikipedia.org/wiki/XFS)
WIKI: Btrfs (http://en.wikipedia.org/wiki/Btrfs)
WIKI: ZFS (http://en.wikipedia.org/wiki/ZFS)
WIKI: Reiser4 (http://en.wikipedia.org/wiki/Reiser4)
- Kexec jump: kexec/kdump based hibernation:
O Kexec é um recurso do Linux que permite que carregar um kernel na memória e executa-lo, ou seja permitindo que se "reinicie em um novo kernel", sem reiniciar o PC.
Assim era implementado o Kdump, um sistema de dump para quando o kernel travava: Um kernel estável/seguro (que se tinha certeza que iria funcionar) era carregado na memória assim que o sistema iniciasse e caso acontecesse do kernel principal do sistema travar o "oops code" executava o Kexec, que passava para o kernel estável/seguro, que então fazia um dump da memória.
Esta implementação foi melhorada no kernel 2.6.27 agora podendo ser usada para fazer a hibernação do sistema, ou seja, o sistema iria chamar o Kexec para executar um segundo kernel que faria o dump da memória em disco e depois desligaria o computador. Quando a máquina fosse religada, o initrd poderia carregar os dados e restaura-los.
Esta implementação de hibernação não substitui as outras, apenas é mais uma alternativa que tem algumas vantagens como não depender da ACPI. Porém por enquanto só funciona em sistemas X86-32.
Links relacionados:
LWN: Yet another approach to software suspend (http://lwn.net/Articles/242107/)
WIKI: Kexec (http://en.wikipedia.org/wiki/Kexec)
WEB: Kdump (http://lse.sourceforge.net/kdump/)
WIKI: Hibernação (http://en.wikipedia.org/wiki/Hibernate_(OS_feature))
WIKI: ACPI (http://en.wikipedia.org/wiki/ACPI)
WIKI: X86-32 (http://en.wikipedia.org/wiki/X86-32)
WIKI: initrd (http://en.wikipedia.org/wiki/Initrd)
- UBIFS:
UBIFS é um novo sistema de arquivos para dispositivos flash, desenvolvido pela Nokia com a Universidade de Szeged.
O UBIFS é bem diferente dos outros sistemas de arquivos tradicionais, ele não trabalha com dispositivos baseados em blocos, mas somente em dispositivos flashs "puros", manipulados pelo subsistema MTD no Linux.
Logo o UBIFS não funciona com o que muitas pessoas consideram dispositivos flashs como HDs flash, cartões SD, pen-drives/USB-sticks, etc, por causa que estes dispositivos utilizam uma camada de emulação para dispositivos de blocos, chamada FTL (Flash Translation Layer) que fazem com que estes dispositivos pareçam ser organizados através de blocos como.
O UBIFS foi feito para os dispositivos que não utilizam o FTL e que são manipulados pelo subsistema MTD e apresentam-se para o userspace como dispositivos MTD.
O UBIFS opera em cima de volumes UBI (Unsorted Block Images). (O UBI é uma camada como o LVM, que entrou no kernel na versão 2.6.22, que este sim opera em cima de dispositivos MTD). O UBIFS oferece diversas vantagens sobre o JFFS2: tempos de montagem mais rápidos e escalonáveis, tolerância a hard-reboots (conhecidos como dedoffs) pois é um sistema com journaling, suporte a write-back e a compressão "on-the-fly".
Links relacionados:
LWN: UBIFS (http://lwn.net/Articles/276025/)
WIKI: MTD (http://en.wikipedia.org/wiki/Memory_Technology_Device)
WIKI: FTL (http://en.wikipedia.org/wiki/Flash_Translation_Layer#Flash_file_systems)
WIKI: Userspace (http://en.wikipedia.org/wiki/Userspace)
WIKI: JFFS2 (http://en.wikipedia.org/wiki/JFFS2)
WIKI: Journaling (http://en.wikipedia.org/wiki/Journaling_file_system)
WEB: UBIFS FAQ (http://www.linux-mtd.infradead.org/faq/ubifs.html)
WEB: UBIFS DOCs (http://www.linux-mtd.infradead.org/doc/ubifs.html)
- OMFS:
OMFS significa "Sonicblue Optimized MPEG File System support" e é um sistema de arquivos proprietário utilizado pelo player de música Rio Karma e o ReplayTV DVR. Desconsiderando o nome, este sistema de arquivos não é mais eficiente que um sistema de arquivos padrão quando se trata de arquivos MPEG.
Links relacionados:
LWN: OMFS (http://lwn.net/Articles/278028/)
- Block layer data integrity support
Sistemas de arquivos modernos contam com o recurso de checksum de dados e meta-dados para proteger-se contra dados corrompidos. Porém a checagem é feita em tempo de leitura, que pode acontecer meses depois dos dados terem sido escritos e neste ponto os dados que a aplicação tentou escrever, provavelmente ja estão perdidos. A solução é verificar que o que esta sendo gravado em disco é o que realmente espera-se.
Recentes adições aos protocolos da família SCSI (SBC Data Integrity Field, SCC protection proposal) e ao SATA/T13 (External Path Protection) tentam melhorar esta situação adicionando suporte a adição de meta-dados de integridade em um I/O. Estes meta-dados de integridade contém um checksum de cada setor e um contador incremental que garante que os dados serão escritos na ordem certa.
Links relacionados:
LWN: Block layer: integrity checking and lots of partitions (http://lwn.net/Articles/290141/)
WIKI: Checksum (http://en.wikipedia.org/wiki/Checksum)
WIKI: SCSI (http://en.wikipedia.org/wiki/SCSI)
WIKI: SATA (http://en.wikipedia.org/wiki/SATA)
- Multiqueue networking:
Uma das principais estruturas de dados do subsistema de redes é a fila associada a cada dispositivo para a transmissão de dados.
Este métodos funcionou muito bem por anos, porém vem encontrando uma barreira ultimamente: Não funciona bem para dispositivos com múltiplas filas.
E dispositivos assim estão se tornando mais comuns, principalmente na área de redes sem fio, como por exemplo os dispositivos que implementam o Wireless Multimedia Extensions que podem ter 4 "classes de serviços", onde alguns serviços podem ter mais prioridades que outros.
O kernel 2.6.27 agora tem suporte a estes dispositivos.
Links relacionados:
LWN : Multiqueue networking (http://lwn.net/Articles/289137/)
WIKI: Wireless Multimedia Extensions (http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions)
- ftrace:
O ftracer é um simples tracer de funções que nasceu na árvore -rt (Real Time) de desenvolvimento.
Ele utiliza um recurso do compilador para inserir uma pequena instrução NOP de 5 bytes no início de cada função do kernel. Então estas instruções NOP são modificadas em tempo de execução em uma chamada ao tracer quando a opção de tracing está habilitada pelo administrador do sistema, caso esta não esteja o overhead encontrado é muito pequeno e desprezível até em micro-benchmarks.
Apesar do ftrace trabalhar com funções ele inclui um sistema de plugins que permite outros tipos de tracing.
Links relacionados:
WIKI: Real Time (http://en.wikipedia.org/wiki/Real-time_operating_system)
WIKI: NOP (http://en.wikipedia.org/wiki/NOP)
WIKI: Overhead (http://en.wikipedia.org/wiki/Computational_overhead)
WIKI: Benchmark (http://en.wikipedia.org/wiki/Benchmark_(computing))
- Mmiotrace:
Mmiotrace é uma ferramenta para capturar acessos MMIO (Memory Mapped IO) no kernel Como o MMIO é utilizado por drivers, esta ferramenta pode ser utilizada para debugging e engenharia reversa de drivers binários.
Links relacionados:
LWN: Tracing memory-mapped I/O operations (http://lwn.net/Articles/270939/)
WIKI: MMIO (http://en.wikipedia.org/wiki/IO_port)
- External firmware:
O Firmware normalmente é compilado junto com o drivers, porém por algumas questões legais (de licenciamento na maioria), a distribuição de alguns firmwares não é permitido por algumas empresas e alguns drivers tem suportado que um firmware externo seja carregado.
Porém mesmo que um firmware, que possa ser legalmente redistribuído, mas não atende as diretivas do "software livre", então algumas pessoas acham que isto quebra a GPL.
No kernel 2.6.27 os firmwares foram movidos de dentro dos códigos do drivers para um novo diretório "firmware/". Por padrão, o firmware não será compilado dentro do kernel (built-in) ou nos módulos, mas serão instalados em /lib/firmware quando o usuário fizer o "make module_install". Os drivers foram modificados também para chamar a função request_firmware() e carregar o firmware que eles necessitarão.
Entretanto ainda há uma opção na configuração do kernel para que os firmwares sejam compilados dentro dos drivers.
Links relacionados:
LWN: Moving the firmware out (http://lwn.net/Articles/284932/)
WIKI: Firmware (http://en.wikipedia.org/wiki/Firmware)
- Improved video camera support with the gspca driver:
A inclusão do driver gspca no kernel 2.6.27 provê suporte a mais uma grande lista de câmeras de vídeo, que pode ser conferida aqui:
http://lwn.net/Articles/291036/
Agora, a maioria das câmeras de vídeo disponíveis no mercado são suportadas no Linux.
- Extended file descriptor system calls:
Quando o Unix foi criado, muitas das interfaces não previam funcionalidades que seriam necessárias no futuro, como por exemplo a criação de um descritor de arquivo que tivesse uma flag como parâmetro. Esta limitação tornava impossível a criação de descritores de arquivo com novas propriedades como "close-on-exec", "non-blocking" e "non-sequential". Tornar isso possível hoje é essencial, inclusive para efeitos de segurança.
O Linux 2.6.27 adicionou um novo set de interfaces e syscalls que serão usadas pela glibc.
Links relacionados:
LWN: Extending system calls (http://lwn.net/Articles/281965/)
WIKI: Descritor de arquivo (http://en.wikipedia.org/wiki/File_descriptor)
WIKI: Syscall (http://en.wikipedia.org/wiki/Syscall)
WIKI: Glibc (http://en.wikipedia.org/wiki/Glibc)
- Voltage and Current Regulator:
Este framework foi criado para implementar uma interface genérica com reguladores de voltagem e corrente. A intenção é permitir que os sistemas ajustem dinamicamente a saída do regulador com o objetivo de economizar bateria e gastar menos energia.
Outras novidades:
X86:
- Adicionado suporte ao AMD IOMMU (AMD I/O Virtualization Technology).
- Suporte a 4096 CPUs.
Xen:
- Permite que o Xen seja executado em 64-bits.
- O Xen agora permite que máquinas virtuais sejam salvas e restauradas.
PowerPC:
- Removida a arquitetura PPC (arch/ppc), agora a POWERPC (arch/powerpc) suporta as duas.
- Kdbg com suporte a PowerPC
Rede:
- Novos drivers ath9k que suportam os chipsets das famílias AR5008 e AR9001 da Atheros.
Segurança:
- O módulo de segurança "dummy" foi removido. Agora o padrão é o módulo "capabilities".
- Suporte aos seguintes algoritmos de hash: RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320.
Outros:
- Suporte ao Palm TX.
- Remoção da arquitetura v850.
E como sempre *muitos* novos drivers, aumentando ainda mais a gama de dispositivos suportados!
Fontes de informação/pesquisa:
http://lwn.net/Articles/289510/
http://lwn.net/Articles/290428/
http://lwn.net/Articles/291461/
http://kernelnewbies.org/Linux_2_6_27
Mesmo o bug das placas de rede e1000e não tendo sido corrigido, o kernel conta com uma série de fixes que impedem que seja causado algum dano ao hardware.
Anyway, vamos dar uma olhada no que
- Lockless page cache:
A "page cache" é o local onde o kernel deixa em memória uma cópia de um arquivo em disco, para evitar I/O.
Existia um lock para evitar problemas em sistemas com múltiplos CPUs, logo quando diferentes CPUs tentavam acessar arquivos diferentes não tínhamos problemas, porém quando dois CPUs tentavam acessar um mesmo arquivo (uma shared library do sistema por exemplo), somente um poderia ler a cada vez. Agora, graças a algumas novas regras que definem como a "page cache" é utilizada e pela utilização de RCU, será possível ler a "page cache" sem ser necessário fazer o lock.
Porém esta melhora só será observada em sistemas com muitas CPUs.
Links relacionados:
LWN: Toward better direct I/O scalability (http://lwn.net/Articles/275808/)
LWN: The lockless page cache (http://lwn.net/Articles/291826/)
WIKI: RCU (http://en.wikipedia.org/wiki/Read-copy-update)
- Lockless get_user_pages():
A função get_user_pages() é utilizada em operações de I/O diretas para travar o espaço de memória que será transferido.
Entretanto é uma função complexa e que utilizada semáforos e locks, que causavam problemas de escalabilidade quando se tinha diversos processos utilizando está função em uma mesma área de memória.
No kernel 2.6.27 uma nova função get_user_pages_fast() foi introduzida, a qual faz a mesma operação que a get_user_pages() porem determinadas operações foram simplificadas de modo que não é necessário obter o semáforo nem o lock. Alguns testes registraram uma melhora de 10% em um sistema quad-core com um banco de dados IBM DB2 com um workload OLTP.
Links relacionados:
WIKI: OLPT (http://en.wikipedia.org/wiki/Online_transaction_processing)
- Ext4: Delayed Allocation:
Neste versão foi adicionado ao sistema de arquivos ext4, um dos mais importantes recursos planejados a "Delayed Allocation" (alocação tardia, conhecida também como Allocate-on-flush).
Este recurso não altera a estrutura do disco, mas melhora a velocidade em diversas situações.
Uma breve explicação de como funciona: Quando uma aplicação quer escrever algo em disco, os dados não são escritos imediatamente, mas são colocados em uma área de memória RAM por algum tempo. Mas independente de ser escrita ou não imediatamente, o sistema de arquivos aloca as estruturas necessárias em disco na hora. A alocação tardia consiste em não alocar estas estruturas para os dados que estão cacheados na RAM, ela apenas atualiza a estrutura que indica quanto espaço livre em disco ainda temos, quando é feita uma operação de escrita. Os blocos e estruturas no disco são somente alocados quando os dados são realmente escritos.
Esta técnica é utilizada por outros sistemas de arquivos como o XFS, Btrfs, ZFS e o Reiser4 e apresenta um notável ganho de velocidade e também resulta em decisões melhores para a alocação dos blocos, pois neste momento o sistema de arquivos ja conhece tudo que deverá escrever.
Links relacionados:
WIKI: EXT4 (http://en.wikipedia.org/wiki/Ext4)
WIKI: Allocate-on-flush (http://en.wikipedia.org/wiki/Allocate-on-flush)
WIKI: Sistema de Arquivos (http://en.wikipedia.org/wiki/Filesystem)
WIKI: XFS (http://en.wikipedia.org/wiki/XFS)
WIKI: Btrfs (http://en.wikipedia.org/wiki/Btrfs)
WIKI: ZFS (http://en.wikipedia.org/wiki/ZFS)
WIKI: Reiser4 (http://en.wikipedia.org/wiki/Reiser4)
- Kexec jump: kexec/kdump based hibernation:
O Kexec é um recurso do Linux que permite que carregar um kernel na memória e executa-lo, ou seja permitindo que se "reinicie em um novo kernel", sem reiniciar o PC.
Assim era implementado o Kdump, um sistema de dump para quando o kernel travava: Um kernel estável/seguro (que se tinha certeza que iria funcionar) era carregado na memória assim que o sistema iniciasse e caso acontecesse do kernel principal do sistema travar o "oops code" executava o Kexec, que passava para o kernel estável/seguro, que então fazia um dump da memória.
Esta implementação foi melhorada no kernel 2.6.27 agora podendo ser usada para fazer a hibernação do sistema, ou seja, o sistema iria chamar o Kexec para executar um segundo kernel que faria o dump da memória em disco e depois desligaria o computador. Quando a máquina fosse religada, o initrd poderia carregar os dados e restaura-los.
Esta implementação de hibernação não substitui as outras, apenas é mais uma alternativa que tem algumas vantagens como não depender da ACPI. Porém por enquanto só funciona em sistemas X86-32.
Links relacionados:
LWN: Yet another approach to software suspend (http://lwn.net/Articles/242107/)
WIKI: Kexec (http://en.wikipedia.org/wiki/Kexec)
WEB: Kdump (http://lse.sourceforge.net/kdump/)
WIKI: Hibernação (http://en.wikipedia.org/wiki/Hibernate_(OS_feature))
WIKI: ACPI (http://en.wikipedia.org/wiki/ACPI)
WIKI: X86-32 (http://en.wikipedia.org/wiki/X86-32)
WIKI: initrd (http://en.wikipedia.org/wiki/Initrd)
- UBIFS:
UBIFS é um novo sistema de arquivos para dispositivos flash, desenvolvido pela Nokia com a Universidade de Szeged.
O UBIFS é bem diferente dos outros sistemas de arquivos tradicionais, ele não trabalha com dispositivos baseados em blocos, mas somente em dispositivos flashs "puros", manipulados pelo subsistema MTD no Linux.
Logo o UBIFS não funciona com o que muitas pessoas consideram dispositivos flashs como HDs flash, cartões SD, pen-drives/USB-sticks, etc, por causa que estes dispositivos utilizam uma camada de emulação para dispositivos de blocos, chamada FTL (Flash Translation Layer) que fazem com que estes dispositivos pareçam ser organizados através de blocos como.
O UBIFS foi feito para os dispositivos que não utilizam o FTL e que são manipulados pelo subsistema MTD e apresentam-se para o userspace como dispositivos MTD.
O UBIFS opera em cima de volumes UBI (Unsorted Block Images). (O UBI é uma camada como o LVM, que entrou no kernel na versão 2.6.22, que este sim opera em cima de dispositivos MTD). O UBIFS oferece diversas vantagens sobre o JFFS2: tempos de montagem mais rápidos e escalonáveis, tolerância a hard-reboots (conhecidos como dedoffs) pois é um sistema com journaling, suporte a write-back e a compressão "on-the-fly".
Links relacionados:
LWN: UBIFS (http://lwn.net/Articles/276025/)
WIKI: MTD (http://en.wikipedia.org/wiki/Memory_Technology_Device)
WIKI: FTL (http://en.wikipedia.org/wiki/Flash_Translation_Layer#Flash_file_systems)
WIKI: Userspace (http://en.wikipedia.org/wiki/Userspace)
WIKI: JFFS2 (http://en.wikipedia.org/wiki/JFFS2)
WIKI: Journaling (http://en.wikipedia.org/wiki/Journaling_file_system)
WEB: UBIFS FAQ (http://www.linux-mtd.infradead.org/faq/ubifs.html)
WEB: UBIFS DOCs (http://www.linux-mtd.infradead.org/doc/ubifs.html)
- OMFS:
OMFS significa "Sonicblue Optimized MPEG File System support" e é um sistema de arquivos proprietário utilizado pelo player de música Rio Karma e o ReplayTV DVR. Desconsiderando o nome, este sistema de arquivos não é mais eficiente que um sistema de arquivos padrão quando se trata de arquivos MPEG.
Links relacionados:
LWN: OMFS (http://lwn.net/Articles/278028/)
- Block layer data integrity support
Sistemas de arquivos modernos contam com o recurso de checksum de dados e meta-dados para proteger-se contra dados corrompidos. Porém a checagem é feita em tempo de leitura, que pode acontecer meses depois dos dados terem sido escritos e neste ponto os dados que a aplicação tentou escrever, provavelmente ja estão perdidos. A solução é verificar que o que esta sendo gravado em disco é o que realmente espera-se.
Recentes adições aos protocolos da família SCSI (SBC Data Integrity Field, SCC protection proposal) e ao SATA/T13 (External Path Protection) tentam melhorar esta situação adicionando suporte a adição de meta-dados de integridade em um I/O. Estes meta-dados de integridade contém um checksum de cada setor e um contador incremental que garante que os dados serão escritos na ordem certa.
Links relacionados:
LWN: Block layer: integrity checking and lots of partitions (http://lwn.net/Articles/290141/)
WIKI: Checksum (http://en.wikipedia.org/wiki/Checksum)
WIKI: SCSI (http://en.wikipedia.org/wiki/SCSI)
WIKI: SATA (http://en.wikipedia.org/wiki/SATA)
- Multiqueue networking:
Uma das principais estruturas de dados do subsistema de redes é a fila associada a cada dispositivo para a transmissão de dados.
Este métodos funcionou muito bem por anos, porém vem encontrando uma barreira ultimamente: Não funciona bem para dispositivos com múltiplas filas.
E dispositivos assim estão se tornando mais comuns, principalmente na área de redes sem fio, como por exemplo os dispositivos que implementam o Wireless Multimedia Extensions que podem ter 4 "classes de serviços", onde alguns serviços podem ter mais prioridades que outros.
O kernel 2.6.27 agora tem suporte a estes dispositivos.
Links relacionados:
LWN : Multiqueue networking (http://lwn.net/Articles/289137/)
WIKI: Wireless Multimedia Extensions (http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions)
- ftrace:
O ftracer é um simples tracer de funções que nasceu na árvore -rt (Real Time) de desenvolvimento.
Ele utiliza um recurso do compilador para inserir uma pequena instrução NOP de 5 bytes no início de cada função do kernel. Então estas instruções NOP são modificadas em tempo de execução em uma chamada ao tracer quando a opção de tracing está habilitada pelo administrador do sistema, caso esta não esteja o overhead encontrado é muito pequeno e desprezível até em micro-benchmarks.
Apesar do ftrace trabalhar com funções ele inclui um sistema de plugins que permite outros tipos de tracing.
Links relacionados:
WIKI: Real Time (http://en.wikipedia.org/wiki/Real-time_operating_system)
WIKI: NOP (http://en.wikipedia.org/wiki/NOP)
WIKI: Overhead (http://en.wikipedia.org/wiki/Computational_overhead)
WIKI: Benchmark (http://en.wikipedia.org/wiki/Benchmark_(computing))
- Mmiotrace:
Mmiotrace é uma ferramenta para capturar acessos MMIO (Memory Mapped IO) no kernel Como o MMIO é utilizado por drivers, esta ferramenta pode ser utilizada para debugging e engenharia reversa de drivers binários.
Links relacionados:
LWN: Tracing memory-mapped I/O operations (http://lwn.net/Articles/270939/)
WIKI: MMIO (http://en.wikipedia.org/wiki/IO_port)
- External firmware:
O Firmware normalmente é compilado junto com o drivers, porém por algumas questões legais (de licenciamento na maioria), a distribuição de alguns firmwares não é permitido por algumas empresas e alguns drivers tem suportado que um firmware externo seja carregado.
Porém mesmo que um firmware, que possa ser legalmente redistribuído, mas não atende as diretivas do "software livre", então algumas pessoas acham que isto quebra a GPL.
No kernel 2.6.27 os firmwares foram movidos de dentro dos códigos do drivers para um novo diretório "firmware/". Por padrão, o firmware não será compilado dentro do kernel (built-in) ou nos módulos, mas serão instalados em /lib/firmware quando o usuário fizer o "make module_install". Os drivers foram modificados também para chamar a função request_firmware() e carregar o firmware que eles necessitarão.
Entretanto ainda há uma opção na configuração do kernel para que os firmwares sejam compilados dentro dos drivers.
Links relacionados:
LWN: Moving the firmware out (http://lwn.net/Articles/284932/)
WIKI: Firmware (http://en.wikipedia.org/wiki/Firmware)
- Improved video camera support with the gspca driver:
A inclusão do driver gspca no kernel 2.6.27 provê suporte a mais uma grande lista de câmeras de vídeo, que pode ser conferida aqui:
http://lwn.net/Articles/291036/
Agora, a maioria das câmeras de vídeo disponíveis no mercado são suportadas no Linux.
- Extended file descriptor system calls:
Quando o Unix foi criado, muitas das interfaces não previam funcionalidades que seriam necessárias no futuro, como por exemplo a criação de um descritor de arquivo que tivesse uma flag como parâmetro. Esta limitação tornava impossível a criação de descritores de arquivo com novas propriedades como "close-on-exec", "non-blocking" e "non-sequential". Tornar isso possível hoje é essencial, inclusive para efeitos de segurança.
O Linux 2.6.27 adicionou um novo set de interfaces e syscalls que serão usadas pela glibc.
Links relacionados:
LWN: Extending system calls (http://lwn.net/Articles/281965/)
WIKI: Descritor de arquivo (http://en.wikipedia.org/wiki/File_descriptor)
WIKI: Syscall (http://en.wikipedia.org/wiki/Syscall)
WIKI: Glibc (http://en.wikipedia.org/wiki/Glibc)
- Voltage and Current Regulator:
Este framework foi criado para implementar uma interface genérica com reguladores de voltagem e corrente. A intenção é permitir que os sistemas ajustem dinamicamente a saída do regulador com o objetivo de economizar bateria e gastar menos energia.
Outras novidades:
X86:
- Adicionado suporte ao AMD IOMMU (AMD I/O Virtualization Technology).
- Suporte a 4096 CPUs.
Xen:
- Permite que o Xen seja executado em 64-bits.
- O Xen agora permite que máquinas virtuais sejam salvas e restauradas.
PowerPC:
- Removida a arquitetura PPC (arch/ppc), agora a POWERPC (arch/powerpc) suporta as duas.
- Kdbg com suporte a PowerPC
Rede:
- Novos drivers ath9k que suportam os chipsets das famílias AR5008 e AR9001 da Atheros.
Segurança:
- O módulo de segurança "dummy" foi removido. Agora o padrão é o módulo "capabilities".
- Suporte aos seguintes algoritmos de hash: RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320.
Outros:
- Suporte ao Palm TX.
- Remoção da arquitetura v850.
E como sempre *muitos* novos drivers, aumentando ainda mais a gama de dispositivos suportados!
Fontes de informação/pesquisa:
http://lwn.net/Articles/289510/
http://lwn.net/Articles/290428/
http://lwn.net/Articles/291461/
http://kernelnewbies.org/Linux_2_6_27
Assinar:
Postagens (Atom)
