Sempre dizem que o bom filho a casa torna (ou retorna, não sei :P).
Então, aqui vou eu =D
E hoje, enviei meu primeiro bug-report ao bugzilla do gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=249878
Basicamente foi um repasse de uma falha que vi na Secunia.
Uma falha no rsyslog que afetas as duas versões que estão na árvore do portage, tanto a 3.18.4 (v-3 stable) quanto a 3.21.6 (v-3 beta).
Foram lançadas as versões 3.20.1 e 3.21.8 que corrigiram um bug de bypass descrito aqui:
http://www.rsyslog.com/Article322.phtml
Logo em seguida, estas duas versões foram retiradas do ar, e foram colocadas 2 outras a 3.20.2 e a 3.21.9 que corrigiam um DoS.
Aqui esta o anúncio da 3.20.2:
http://www.rsyslog.com/Article324.phtml
E aqui o da 3.21.9:
http://www.rsyslog.com/Article327.phtml
Foi bem legal reportar o bug, e o Stupendoussteve do canal #gentoo-security me ajudou pra caramba... espero que ninguém que siga a security@gentoo.org fique *muito* puto por 1 ou 2 edits a mais que tive que fazer :P
Na verdade eu voltei a acompanhar o bugzilla mais por causa do KernelTeam do Gentoo... estão precisando mais de gente do que o SecurityTeam. Mas nada impede que eu tente ajudar os dois e foi um bom para me acostumar com o funcionamento do Bugzilla =D
Será que o primeiro bug report, a gente nunca esquece? :P
Mostrando postagens com marcador kernel. Mostrar todas as postagens
Mostrando postagens com marcador kernel. Mostrar todas as postagens
quinta-feira, 4 de dezembro de 2008
domingo, 26 de outubro de 2008
Trocando de distro a cada 6 meses?
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... =]
"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... =]
quarta-feira, 15 de outubro de 2008
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
domingo, 13 de julho de 2008
Lançado Linux (Kernel) 2.6.26
Hoje foi lançada a versão 2.6.26 do kernel. Com um ciclo de desenvolvimento de aproximadamente 3 meses e depois de 9 RCs, temos a criança :P
Aqui esta uma pequena estatística de onde o código sofreu mais mudanças desde a versão .25:
Como podem ver, metade foi na parte de drivers mesmo, com destaque para a parte de wireless, a remoção do driver sk98lin (obsoleto) e bastante coisa na parte de vídeo (V4L).
A grande mudança no diretório Arch se deve a ports do KVM, suporte a PAT (Page Attribute Table) no x86, o KGDB e a implementação do semáforo genérico que veio para substituir os específicos de cada arquitetura e reduzir a repetição de código (e COMO reduziu).
Apenas lembrando que isso são as maiores porcentagens de milhares de linhas de códigos alteradas/modificas/removidas, então nem pensem que somente isso foi trabalhado =]
Agora vamos ao resumo das novidades (aka Cool Things) do KernelNewbies:
1 - Support for read-only bind mounts:
Recomendado: http://lwn.net/Articles/281157/
2 - x86 PAT (Page Attribute Tables):
3 - PCI Express ASPM (Active State Power Management)
4 - Ports of KVM to IA64, S390 and PPC:
5 - Other KVM improvements including basic paravirtualization support
6 - Preliminar support of the future 802.11s wireless mesh standard
7 - Much improved webcam support thanks to a driver for UVC devices
8 - Built-in memory tester
9 - Kernel debugger (KGDB)
10 - BDI statistics and parameters exposure in /sys/class/bdi
11 - New /proc/PID/mountinfo file for more accurate information about mounts
12 - Per-process securebits
Recomendado: http://lwn.net/Articles/280279/
13 - Device white-list for containers users
Recomendado: http://lwn.net/Articles/273822/
14 - Support for the OLPC
15 - Some new drivers and many small improvements
Para ver um resumo mais completo das mudanças, recomendo ver:
http://kernelnewbies.org/Linux_2_6_26
(Pois o change-log inteiro é looooooongo)
Aqui esta uma pequena estatística de onde o código sofreu mais mudanças desde a versão .25:
4.9% arch/arm/
9.0% arch/powerpc/configs/
11.8% arch/powerpc/
28.7% arch/
5.0% drivers/media/video/
9.2% drivers/media/
5.5% drivers/net/sk98lin/
6.6% drivers/net/wireless/
17.8% drivers/net/
4.8% drivers/s390/net/
5.3% drivers/s390/
49.7% drivers/
6.4% include/
5.1% net/
Como podem ver, metade foi na parte de drivers mesmo, com destaque para a parte de wireless, a remoção do driver sk98lin (obsoleto) e bastante coisa na parte de vídeo (V4L).
A grande mudança no diretório Arch se deve a ports do KVM, suporte a PAT (Page Attribute Table) no x86, o KGDB e a implementação do semáforo genérico que veio para substituir os específicos de cada arquitetura e reduzir a repetição de código (e COMO reduziu).
Apenas lembrando que isso são as maiores porcentagens de milhares de linhas de códigos alteradas/modificas/removidas, então nem pensem que somente isso foi trabalhado =]
Agora vamos ao resumo das novidades (aka Cool Things) do KernelNewbies:
1 - Support for read-only bind mounts:
Since 2.4.0 Linux has supported bind mounts. Bind mounts are a sort of directory symlinks that allow to share the contents of a directory in two different paths. For example, "mount --bind /foo /bar" will "bind" the contents of /foo not only to /foo, but also /bar. IOW, /foo and /bar would have the same content - and any modification in one directory is visible in the other. This has been useful for things like chroots or ftp/webservers, but until now, if /foo was writable, there was no way to stop /bar from being also writable.
In Linux 2.6.26, you can make those bind mounts read-only. If we made the bind mount in the previous example read-only, the contents of /foo would show up in /bar - but an application trying to modify a file in /bar will not be able to do it (/foo could continue being writable, of course). This has a number of uses. It allows chroots to have parts of filesystems writable. It's useful for containers because users may have root inside a container, but should not be allowed to write to some filesystems. It allows security enhancement by making sure that parts of your filesystem read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated.
(The current implementation does not allow to make a bind mount directly read-only: you need to make the bind mount first - mount --bind /foo /bar - and then remount the bind as ro - mount -o remount,ro /bar)
Recomendado: http://lwn.net/Articles/281157/
2 - x86 PAT (Page Attribute Tables):
PAT (Page Attribute Table) is a feature found in x86 processors that allows for setting the memory attribute at the page level granularity. PAT is complementary to the MTRR settings which allows for setting of memory types over physical address ranges. However, PAT is more flexible than MTRR due to its capability to set attributes at page level and also due to the fact that there are no hardware limitations on number of such attribute settings allowed. It's not a very new feature: the Linux support for this has been in the works for a long time: the current patches are evolved from ones started in 2006, and there're traces of preliminary patches in 2001. Probably because it's not a critical feature and MTRRs did the job.
3 - PCI Express ASPM (Active State Power Management)
4 - Ports of KVM to IA64, S390 and PPC:
KVM, the virtualization solution included in Linux 2.6.20, has been rearchitected to give support to architectures other than x86: IA64 (Itanium), S390 and PPC
5 - Other KVM improvements including basic paravirtualization support
6 - Preliminar support of the future 802.11s wireless mesh standard
A year ago, in Linux 2.6.22, Linux included a new wireless stack. In 2.6.26 that stack is adding support for the draft of wireless mesh networking (802.11s), thanks to the open80211s project (http://www.open80211s.org/)
7 - Much improved webcam support thanks to a driver for UVC devices
2.6.26 inclues a driver that supports video input devices compliant with the USB Video Class specification (http://en.wikipedia.org/wiki/USB_video_device_class). This means lots of currently manufactured webcams (http://linux-uvc.berlios.de/#devices), and probably most of the future ones
8 - Built-in memory tester
Memtest is a commonly used tool for checking your memory. In 2.6.26 Linux is including his own in-kernel memory tester. The goal is not to replace memtest, in fact this tester is much simpler and less capable than memtest, but it's handy to have a built-in memory tester on every kernel. It's enabled easily with the "memtest" boot parameter.
9 - Kernel debugger (KGDB)
For many years Linux has not included a kernel debugger. Linus Torvalds vetoed them for years, for reasons that he explained quite well in a know email: "When things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger [...] I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_."
Despite of those objections, many people wanted a debugger and KGDB is finally going in. It's a remote debugger, it needs two machines. x86 and sparc machines are supported
10 - BDI statistics and parameters exposure in /sys/class/bdi
Linux 2.6.24 merged per-device dirty thresholds: The limits that the kernel put to the amount of memory that a process can "dirty" changed from being global to be per-device. 2.6.26 exposes a interface in /sys/class/bdi that allow to set several parameters. There's another set of read-only parameters that are exposet in debugfs (debug/bdi//stats)
11 - New /proc/PID/mountinfo file for more accurate information about mounts
The work being done these days in the VFS like per-process namespaces and such is obsoleting some things, like /proc/mounts (which is always a link to /proc/self/mounts). In its current form lacks important information and suffers some problems (see the code link). 2.6.26 introduces /proc/PID/mountinfo which addresses these deficiencies. Information about the information that can be found on these new files is explained in the commit links.
12 - Per-process securebits
Filesystem capability support makes it possible to do away with (set)uid-0 based privilege and use capabilities instead. That is, with filesystem support for capabilities but without this present feature, it is (conceptually) possible to manage a system with capabilities alone and never need to obtain privilege via (set)uid-0. Of course, conceptually isn't quite the same as currently possible since few user applications, certainly not enough to run a viable system, are currently prepared to leverage capabilities to exercise privilege. Further, many applications exist that may never get upgraded in this way, and the kernel will continue to want to support their setuid-0 base privilege needs. Where pure-capability applications evolve and replace setuid-0 binaries, it is desirable that there be a mechanisms by which they can contain their privilege. In addition to leveraging the per-process bounding and inheritable sets, this should include suppressing the privilege of the uid-0 superuser from the process' tree of children. The feature added in 2.6.26 can be leveraged to suppress the privilege associated with (set)uid-0. This suppression requires CAP_SETPCAP to initiate, and only immediately affects the 'current' process (it is inherited through fork()/exec()). This reimplementation differs significantly from the historical support for securebits which was system-wide, unwieldy and which has ultimately withered to a dead relic in the source of the modern kernel.
Recomendado: http://lwn.net/Articles/280279/
13 - Device white-list for containers users
This feature implements a functionality wanted by some virtualization users: The ability to control the access to devices in a per-container basis. A cgroup is used to track and enforce open and mknod restrictions on device files. More details can be found in the commit link.
Recomendado: http://lwn.net/Articles/273822/
14 - Support for the OLPC
15 - Some new drivers and many small improvements
Para ver um resumo mais completo das mudanças, recomendo ver:
http://kernelnewbies.org/Linux_2_6_26
(Pois o change-log inteiro é looooooongo)
domingo, 11 de maio de 2008
Quickshots
GCC 4.3.1 Status Report
O GCC 4.3.1 estava agendado para 05/05 mas como ainda existem 3 bugs de Prioridade 1 (máxima), a liberação do RC1 foi adiada.
Os bugs são:
- a restricted pointers bug (36013).
- the x86 direction flag issue (36079). Há uma notícia sobre isso na ultima revista do GRIS.
- ppc64 cacoshl miscompilation (36090).
------
Lançado o OpenSolaris 2008.5
Não tenho o que dizer, apenas que foi bastante comentado... realmente não planejo testa-lo.
------
SP3 do XP finalmente saiu
Depois de sair, voltar, sair de novo... finalmente temos ele ai.
Mas nem tudo são flores no lindo campo verde do Windows XP, parece que algumas pessoas com computadores montados por empresas como HP, e que utilizam processadores AMD, estão tendo problemas de reboot infinitos pois o SP3 futucou os drivers de gerenciamento de energia e acaba misturando coisa da Intel e da AMD.
------
Deputado quer proibir novos feriados no Estado do Rio
Não levantando o mérito se quem propôs a idéia realmente trabalha ou só mama. Mas a idéia foi boa.
O Brasil não é um país de primeiro mundo caralho... e ainda queremos sair criando feriados e enforcando trocentos outros dias. Puta que pariu... e o pior é ver nego defender os feriados.
Que porra de feriado de São Jorge é aquele??? OMFG...
------
Liberado Linux 2.6.25.2, 2.6.25.3, 2.6.25.31415926
O motivo do .2 é uma falha de segurança que por causa de uma Race Condition em conjunto com algumas outras coisas pode permitir uma elevação de privilégio.
O .3 corrige além de outras coisas, 2 bugs que tem implicação com a segurança do sistema também. Também é recomendável que quem estiver usando a série 2.6.24.y atualize para a série 2.6.25.x.
O GCC 4.3.1 estava agendado para 05/05 mas como ainda existem 3 bugs de Prioridade 1 (máxima), a liberação do RC1 foi adiada.
Os bugs são:
- a restricted pointers bug (36013).
- the x86 direction flag issue (36079). Há uma notícia sobre isso na ultima revista do GRIS.
- ppc64 cacoshl miscompilation (36090).
------
Lançado o OpenSolaris 2008.5
Não tenho o que dizer, apenas que foi bastante comentado... realmente não planejo testa-lo.
------
SP3 do XP finalmente saiu
Depois de sair, voltar, sair de novo... finalmente temos ele ai.
Mas nem tudo são flores no lindo campo verde do Windows XP, parece que algumas pessoas com computadores montados por empresas como HP, e que utilizam processadores AMD, estão tendo problemas de reboot infinitos pois o SP3 futucou os drivers de gerenciamento de energia e acaba misturando coisa da Intel e da AMD.
------
Deputado quer proibir novos feriados no Estado do Rio
Não levantando o mérito se quem propôs a idéia realmente trabalha ou só mama. Mas a idéia foi boa.
O Brasil não é um país de primeiro mundo caralho... e ainda queremos sair criando feriados e enforcando trocentos outros dias. Puta que pariu... e o pior é ver nego defender os feriados.
Que porra de feriado de São Jorge é aquele??? OMFG...
------
Liberado Linux 2.6.25.2, 2.6.25.3, 2.6.25.31415926
O motivo do .2 é uma falha de segurança que por causa de uma Race Condition em conjunto com algumas outras coisas pode permitir uma elevação de privilégio.
O .3 corrige além de outras coisas, 2 bugs que tem implicação com a segurança do sistema também. Também é recomendável que quem estiver usando a série 2.6.24.y atualize para a série 2.6.25.x.
sábado, 3 de maio de 2008
Quickshots
Hoje tivemos o segundo treino online para maratona de programação... e utilizando problemas bem "difíceis" e com simulação dos times que participaram na época (sim.. eramos nós contra times :P) cheguei a 2 conclusões:
a) OMFG... tenho que treinar muito ainda.
b) OMFG... mesmo resolvendo apenas 2 de 10 fiquei em 59 de 98. Quantos times de 3 pessoas não resolveram nem 2 O.o
------
Saiu o Linux 2.6.26-rc1.
Teve até uma discussão... err... "acalorada" sobre o ritimo em que patches são adicionados ao kernel. OMFG... é pra isso que existe esse tempo de "merge" (não pra enfiar porcaria la, mas para adicionar *muitas* coisas). Depois fica todo mundo mesmo até o -rcX (X >= 7 normalmente :P) arrumando os pequenos problemas. :P
------
Foi lançado o KDE 4.1 Alpha 1.
Ou seja, o primeiro passo na estabilização do que la para Junho/Julho será o KDE 4.1.
Muita gente fala que o KDE 4.0 (atualmente 4.0.3) não é tão bom quanto disseram que seria. Concordo que talvez na parte de aplicativos não seja, pois uma parte ainda não foi portada para o KDE 4 (com QT 4 e os frameworks do KDE 4). Mas para quem se interessa mais pela parte "debaixo dos panos" da coisa, é incrível ver os novos frameworks do KDE. Vale a pena uma estudada rápida =]
Droga! Nem deixaram eu terminar de estudar sobre o QT 4.3 e ja tão indo pro 4.4. Ta ficando o .NET e seus frameworks :P
------
Metal Gear Boobies
Essa tirinha ta *muito* boa =D
------
E para finalizar... eu *odeio* (S)ML (Mas gostaria de aprender Haskell... mas vamos por partes e deixar Haskell para o ano que vem).
a) OMFG... tenho que treinar muito ainda.
b) OMFG... mesmo resolvendo apenas 2 de 10 fiquei em 59 de 98. Quantos times de 3 pessoas não resolveram nem 2 O.o
------
Saiu o Linux 2.6.26-rc1.
Teve até uma discussão... err... "acalorada" sobre o ritimo em que patches são adicionados ao kernel. OMFG... é pra isso que existe esse tempo de "merge" (não pra enfiar porcaria la, mas para adicionar *muitas* coisas). Depois fica todo mundo mesmo até o -rcX (X >= 7 normalmente :P) arrumando os pequenos problemas. :P
------
Foi lançado o KDE 4.1 Alpha 1.
Ou seja, o primeiro passo na estabilização do que la para Junho/Julho será o KDE 4.1.
Muita gente fala que o KDE 4.0 (atualmente 4.0.3) não é tão bom quanto disseram que seria. Concordo que talvez na parte de aplicativos não seja, pois uma parte ainda não foi portada para o KDE 4 (com QT 4 e os frameworks do KDE 4). Mas para quem se interessa mais pela parte "debaixo dos panos" da coisa, é incrível ver os novos frameworks do KDE. Vale a pena uma estudada rápida =]
Droga! Nem deixaram eu terminar de estudar sobre o QT 4.3 e ja tão indo pro 4.4. Ta ficando o .NET e seus frameworks :P
------
Metal Gear Boobies
Essa tirinha ta *muito* boa =D
------
E para finalizar... eu *odeio* (S)ML (Mas gostaria de aprender Haskell... mas vamos por partes e deixar Haskell para o ano que vem).
sexta-feira, 18 de abril de 2008
Lançado kernel 2.6.25
Mensagem oficial:
http://lkml.org/lkml/2008/4/16/489
http://thread.gmane.org/gmane.linux.kernel/666834
Resumos:
"Linus has released the 2.6.25 kernel. After nearly three months of development and the merging of over 12,000 patches from almost 1200 developers, this kernel is now considered ready for wider use. Highlights of this release include the ath5k (Atheros wireless) driver, a bunch of realtime work including realtime group scheduling, preemptable RCU, LatencyTop support, a number of new ext4 filesystem features, support for the controller area network protocol, more network namespace work, the return of the timerfd() system call, the page map patches (providing much better information on system memory use), the SMACK security module, better kernel support for Intel and ATI R500 graphics chipsets, the memory use controller, ACPI thermal regulation support, MN10300 architecture support, and much more. See the KernelNewbies 2.6.25 page for lots of details, or the full changelog for unbelievable amounts of detail."
Lwn.net: http://lwn.net/Articles/278014
"Summary: 2.6.25 includes support of a new architecture (MN10300/AM33) and the widely used Orion SoCs, a new interface for more accurate measurement of process memory usage, a 'memory resource controller' for controlling the memory usage of groups of processes, realtime group scheduling, a tool for measuring high latencies called latencytop, ACPI thermal regulation, timer event notifications through file descriptors, an alternative MAC security framework called SMACK, a ext4 update, BRK and PIE-executable address space randomization, RCU preemption support, FIFO spinlocks in x86, EFI support in x86-64, a new network protocol called CAN, initial ATI r500 DRI/DRM support, improved device support and many other small improvements."
Kernelnewbies.org: http://kernelnewbies.org/Linux_2_6_25
(muito bom... fala bastante sobre um monte de coisas novas =D)
Full changelog (7 Mb de texto):
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25
Esse demorou... depois de 9 RCs... só saiu quando o Ingo achou um bug fdp que tava dando uma regressão safada. E o bug nem era novo... era velho... mas só foi "ativado" por causa de algum novo patch nesse ciclo de desenvolvimento.
A abertura para novos patches para o 2.6.26 ja começou bombando... muita coisa do KVM, XFS e do x86 (mudanças na escala de 20.000 linha nesse ultimo).
E deve continuar assim até o rc[1-3]... onde ai tudo começa a estabilizar mesmo =D
Anyway, enjoy =D
PS: Caso queiram compilar na mão, ao invés de esperar sua distro... ja sabem o caminho: http://www.kernel.org =]
http://lkml.org/lkml/2008/4/16/489
http://thread.gmane.org/gmane.linux.kernel/666834
Resumos:
"Linus has released the 2.6.25 kernel. After nearly three months of development and the merging of over 12,000 patches from almost 1200 developers, this kernel is now considered ready for wider use. Highlights of this release include the ath5k (Atheros wireless) driver, a bunch of realtime work including realtime group scheduling, preemptable RCU, LatencyTop support, a number of new ext4 filesystem features, support for the controller area network protocol, more network namespace work, the return of the timerfd() system call, the page map patches (providing much better information on system memory use), the SMACK security module, better kernel support for Intel and ATI R500 graphics chipsets, the memory use controller, ACPI thermal regulation support, MN10300 architecture support, and much more. See the KernelNewbies 2.6.25 page for lots of details, or the full changelog for unbelievable amounts of detail."
Lwn.net: http://lwn.net/Articles/278014
"Summary: 2.6.25 includes support of a new architecture (MN10300/AM33) and the widely used Orion SoCs, a new interface for more accurate measurement of process memory usage, a 'memory resource controller' for controlling the memory usage of groups of processes, realtime group scheduling, a tool for measuring high latencies called latencytop, ACPI thermal regulation, timer event notifications through file descriptors, an alternative MAC security framework called SMACK, a ext4 update, BRK and PIE-executable address space randomization, RCU preemption support, FIFO spinlocks in x86, EFI support in x86-64, a new network protocol called CAN, initial ATI r500 DRI/DRM support, improved device support and many other small improvements."
Kernelnewbies.org: http://kernelnewbies.org/Linux_2_6_25
(muito bom... fala bastante sobre um monte de coisas novas =D)
Full changelog (7 Mb de texto):
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25
Esse demorou... depois de 9 RCs... só saiu quando o Ingo achou um bug fdp que tava dando uma regressão safada. E o bug nem era novo... era velho... mas só foi "ativado" por causa de algum novo patch nesse ciclo de desenvolvimento.
A abertura para novos patches para o 2.6.26 ja começou bombando... muita coisa do KVM, XFS e do x86 (mudanças na escala de 20.000 linha nesse ultimo).
E deve continuar assim até o rc[1-3]... onde ai tudo começa a estabilizar mesmo =D
Anyway, enjoy =D
PS: Caso queiram compilar na mão, ao invés de esperar sua distro... ja sabem o caminho: http://www.kernel.org =]
sábado, 26 de janeiro de 2008
Novidades do Linux 2.6.24
A mais nova versão do Linux foi lançado a alguns dias atrás.
Se alguem se interessar, pode ver o changelog completo aqui:
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24
Se quiser, pode ler de uma forma mais "humana" o que foi incluído no kernel, pelo KernelNewbies.
Temos muita coisa nova legal:
E falando de 2.6.25... ja tem bastante coisa legal que vai entrar nele. Agora com a janela de merge aberta, deve vir um fluxo grande de código.
Anyway, algumas coisas interessantes:
Se alguem se interessar, pode ver o changelog completo aqui:
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24
Se quiser, pode ler de uma forma mais "humana" o que foi incluído no kernel, pelo KernelNewbies.
Temos muita coisa nova legal:
- Aperfeiçoamentos do CFS: Tanto em questão de velocidade quanto em tamanho. O CFS tinha uma perda de 10% em relação ao agendador antigo, na troca de contexto. Agora com as otimizações ele está até um pouco mais rápido que o antigo. Alem disso, o tamanho do binário foi reduzido um pouco em UP e consideravelmente em SMP (Multiprocessamento/Processamento Simétrico). Alem disso tivemos a inserção do Fair Group Scheduling no CFS.
- Tickless para x86-64.
- Mais progresso na parte de suporte a WiFi. 2.3 Mb de drivers novos, utilizando a nova stack. Entre eles os b43 e o b43legacy! Mas ainda é preciso extrair o firmware manualmente a partir de um driver =[ (um dia minha broadcom vai funcionar decentemente \o/)
- Patches para evitar a fragmentação da memória. Nunca tive problemas com isto, mas para quem deixa o pc sempre ligado por dias é sempre uma boa.
- Autorização de dispositivos USB. Permite controlar se quando um dispositivo USB for conectado ele esteja disponível aos usuários ou não. Isto hoje pode parecer não ter muito sentido, mas com o Wireless USB, terá.
- Limites de buffer para escritas agora são separados por dispositivos.
- Linux Kernel Markers. Parece ser interessante :P
- Re-unificação das arquiteturas x86-32 e x86-64. Por enquanto apenas todos os arquivos foram movidos para um mesmo diretório. A unificação entre arquivos mesmo... começa a partir do 2.6.25 (leia mais abaixo =])
- Novo driver uvesafb - uma versão melhorada do vesafb
- Escolha aleatória de porta para conexões UDP, assim como é feito com TCP.
- Melhorias no e2fsck com o ext4, ja que o ext4 suporta "Uninitialized Block Groups".
- IPv6 no NFS
- Backport de parte do código do ext3 para o ext2, melhorando muito o desempenho.
- Redução do overhead de leitura e escrita do SELinux. (Apesar de eu ainda não entender o SELinux :P)
- E muito mais coisa que eu ficaria tanto tempo aqui para listar que já teria saido o 2.6.25 :P
E falando de 2.6.25... ja tem bastante coisa legal que vai entrar nele. Agora com a janela de merge aberta, deve vir um fluxo grande de código.
Anyway, algumas coisas interessantes:
- Continuação do merge das arquiteturas x86-32 e x86-64: http://kerneltrap.org/Linux/x86_Architecture_Changes_Merging_in_2.6.25
- Mais melhorias no ext4: http://kerneltrap.org/Linux/Ext4_2.6.25_Merge_Plans
- E mais melhorias no agendador: http://kerneltrap.org/node/15345
Assinar:
Postagens (Atom)
