Tim Bunce deu uma palestra na OSCON deste ano (semana passada), falando sobre alguns "mitos populares" sobre o Perl. Mais especificamente, os 3: Perl está morto, Perl é difícil de ler/testar/manter e Perl 6 esta matando Perl 5.
Se alguem não conhece ele, podem confiar que ele tem experiência para falar de Perl :P
Ele disponibilizou 2 versões, os slides e os slides com anotações.
quarta-feira, 30 de julho de 2008
6 meses de Arch Linux
Caramba, hoje eu me toquei... ja estou com o Arch Linux a 6 meses no meu notebook!
Acho que nada durou tanto tempo assim :P
E rodando um sistema 64 bits puro, sem bibliotecas de 32 para fazer emulação alguma (até por que flash é para os fracos).
Mas posso dizer que foi uma das distro que eu mais gostei de usar e disparado como o motivo principal disso foi o pacman (não, não é este pacman). Simplesmente fantástico, sempre com pacotes bleeding edge, eu sempre tive no meu sistema a ultima versão do kernel, a ultima versão do gcc, a ultima versão da libc... e sem precisar compilar nada na mão!
Sim, talvez isso não me traga nenhum benefício, mas eu gosto, e por isso eu gosto tanto do Arch =D
Ele acaba dando mais trabalho que distros mais "automáticas", ele não futuca em nenhum arquivo de configuração seu. Na verdade, ele não configura nada para você. É seu trabalho deixar o sistema como você gosta. Assim como no gentoo, quando é utilizado o portage, ele pede que você faça os diffs e atualize os arquivos de configuração correspondentes.
Não que eu tenha visto muito isso... pois se tava funcionando, normalmente eu deixava como tava :P
Outra... problemas de dependências travadas e outras coisas sobrenaturais que ja me aconteceram (e muito) em outros gerenciadores de pacotes tanto com o apt, em sistemas baseados em rpm e principalmente no gentoo (quando eu saia fazendo unmask de tudo porque queria as coisas bleeding edge do unstable =D).
Alem disso o AUR é sensacional, pode-se encontrar de tudo ali. E com o Yaourt fica tudo mais fácil! Recomendo a instalação deste.
Resumindo: O pacman foi responsável por 6 meses, onde eu estive bem satisfeito na minha instalação linux :P
Agora a parte ruim... chegou a hora de mudar novamente. Eu tenho que fazer isso =D
Com certeza o Arch ficará como uma das opções que eu sei que sempre vai conseguir me atender muito bem(apesar do trabalho que dá para fazer a instalação :P).
Mas por motivos de compatibilidade e outras cositas mais... estou querendo colocar um sistema 32 bits (puro, não 64 bits, com emulação de 32) em meu notebook.
(Talvez, quem sabe, eu não coloco o Arch no meu Desktop que está atualmente sem um ambiente linux (shame! :P)... vamos ver, mas voltando ao notebook.)
Algumas opções são:
* Voltar ao Kubuntu. Não é bleeding edge (primeira coisa que me vem a cabeça :).
E tem um problema, não vou usar releases Alpha/Beta... e estamos no meio de um ciclo. Então não vou pegar nem o que acabou de sair, e vou ter que esperar ainda uns 3 meses até o próximo. Oh crap...
* Mais uma tentativa com o FreeBSD ou um de seus derivados (PC-BSD, Desktop BSD). O Free foi sempre um sistema que me chamou a atenção... pena que ele não fazia boot no meu notebook -_-'. Mas não cheguei a testar a ultima versão 7.0... talvez seja uma boa =]
* Voltar ao Sabayon. Agora na versão 3.5, com um gerenciador de pacotes refeito (Entropy), que se assemelha ainda mais ao ports do BSD (emho). Um Portage++ praticamente. E eu sempre gostei desta distro, não sei se por causa dela ser baseada no gentoo (que apesar de me dar dor de cabeça, eu tenho muito apreço).
Essas 3, são as opções que mais penso no momento. Quem sabe até este final de semana eu ja não tenha mudado? =]
Acho que nada durou tanto tempo assim :P
E rodando um sistema 64 bits puro, sem bibliotecas de 32 para fazer emulação alguma (até por que flash é para os fracos).
Mas posso dizer que foi uma das distro que eu mais gostei de usar e disparado como o motivo principal disso foi o pacman (não, não é este pacman). Simplesmente fantástico, sempre com pacotes bleeding edge, eu sempre tive no meu sistema a ultima versão do kernel, a ultima versão do gcc, a ultima versão da libc... e sem precisar compilar nada na mão!
Sim, talvez isso não me traga nenhum benefício, mas eu gosto, e por isso eu gosto tanto do Arch =D
Ele acaba dando mais trabalho que distros mais "automáticas", ele não futuca em nenhum arquivo de configuração seu. Na verdade, ele não configura nada para você. É seu trabalho deixar o sistema como você gosta. Assim como no gentoo, quando é utilizado o portage, ele pede que você faça os diffs e atualize os arquivos de configuração correspondentes.
Não que eu tenha visto muito isso... pois se tava funcionando, normalmente eu deixava como tava :P
Outra... problemas de dependências travadas e outras coisas sobrenaturais que ja me aconteceram (e muito) em outros gerenciadores de pacotes tanto com o apt, em sistemas baseados em rpm e principalmente no gentoo (quando eu saia fazendo unmask de tudo porque queria as coisas bleeding edge do unstable =D).
Alem disso o AUR é sensacional, pode-se encontrar de tudo ali. E com o Yaourt fica tudo mais fácil! Recomendo a instalação deste.
Resumindo: O pacman foi responsável por 6 meses, onde eu estive bem satisfeito na minha instalação linux :P
Agora a parte ruim... chegou a hora de mudar novamente. Eu tenho que fazer isso =D
Com certeza o Arch ficará como uma das opções que eu sei que sempre vai conseguir me atender muito bem(apesar do trabalho que dá para fazer a instalação :P).
Mas por motivos de compatibilidade e outras cositas mais... estou querendo colocar um sistema 32 bits (puro, não 64 bits, com emulação de 32) em meu notebook.
(Talvez, quem sabe, eu não coloco o Arch no meu Desktop que está atualmente sem um ambiente linux (shame! :P)... vamos ver, mas voltando ao notebook.)
Algumas opções são:
* Voltar ao Kubuntu. Não é bleeding edge (primeira coisa que me vem a cabeça :).
E tem um problema, não vou usar releases Alpha/Beta... e estamos no meio de um ciclo. Então não vou pegar nem o que acabou de sair, e vou ter que esperar ainda uns 3 meses até o próximo. Oh crap...
* Mais uma tentativa com o FreeBSD ou um de seus derivados (PC-BSD, Desktop BSD). O Free foi sempre um sistema que me chamou a atenção... pena que ele não fazia boot no meu notebook -_-'. Mas não cheguei a testar a ultima versão 7.0... talvez seja uma boa =]
* Voltar ao Sabayon. Agora na versão 3.5, com um gerenciador de pacotes refeito (Entropy), que se assemelha ainda mais ao ports do BSD (emho). Um Portage++ praticamente. E eu sempre gostei desta distro, não sei se por causa dela ser baseada no gentoo (que apesar de me dar dor de cabeça, eu tenho muito apreço).
Essas 3, são as opções que mais penso no momento. Quem sabe até este final de semana eu ja não tenha mudado? =]
terça-feira, 29 de julho de 2008
Fallout 3
Agora na primavera (outono lá em cima, doh!), está agendado para sair a sequência de um dos jogos mais legais (se não o mais) que ja tive o prazer de jogar.
E apesar de não ser o trailer mais novo, colocarei aqui, pois ele é simplesmente muito bom:
E acabaram de anunciar que a versão para PC também terá a disposição conteúdo para download, que antes estava somente planejado para o 360.
Ainda pretendo jogar o Stalker também (e agora deve sair também o segundo)... na verdade eu ainda quero jogar muita coisa, maldito dia de apenas 24 hrs :P
Anyway... estou esperando com bastante ansiedade o Fallout 3... porque vocês sabem... War... War Never Changes.
E apesar de não ser o trailer mais novo, colocarei aqui, pois ele é simplesmente muito bom:
E acabaram de anunciar que a versão para PC também terá a disposição conteúdo para download, que antes estava somente planejado para o 360.
Ainda pretendo jogar o Stalker também (e agora deve sair também o segundo)... na verdade eu ainda quero jogar muita coisa, maldito dia de apenas 24 hrs :P
Anyway... estou esperando com bastante ansiedade o Fallout 3... porque vocês sabem... War... War Never Changes.
Voltando...
Depois de um tempo meio sumido (pelo menos aqui do blog), estou voltando.
Planejo voltar a postar com mais frequência (e que isso não seja somente pela próximas semanas :P).
Com as aulas da faculdade retornando na semana que vem (isso me lembra que deveria dar uma atualizada no que eu chamo de minha página do dcc... aquela linda página branca), OpenHouse do GUL e do GRIS para os calouros... e mais um monte de matéria =]
Não que isso indique que eu tive férias... bem, isso também não significa que eu sei o significado dessa palavra a algum tempo :P
Cya!
Planejo voltar a postar com mais frequência (e que isso não seja somente pela próximas semanas :P).
Com as aulas da faculdade retornando na semana que vem (isso me lembra que deveria dar uma atualizada no que eu chamo de minha página do dcc... aquela linda página branca), OpenHouse do GUL e do GRIS para os calouros... e mais um monte de matéria =]
Não que isso indique que eu tive férias... bem, isso também não significa que eu sei o significado dessa palavra a algum tempo :P
Cya!
segunda-feira, 14 de julho de 2008
Mais uma no senado...
Pessoal,
Não sei se vocês estão sabendo, mas esse caso estourou semana passada na internet. Não sei se foi divulgado em jornais, mas muitos blogs e listas de discussões confirmaram isso.
O caso foi o seguinte:
Nossa incrível senado federal, fechou um contrato com o site www.paraiba.com.br, no valor de R$ 48.000 POR MES (R$ 576.000 POR ANO) para colocar um banner de 120x60 px.
Se vocês não tem noção do que é isso, é o tamanho de um botão de OK do windows.
O acesso deste site é MUITO BAIXO, não justificando o pagamento de quantia alguma (ainda mais nesse valor) para uma forma de propaganda.
Mas agora vamos as coincidências...
O domínio paraiba.com.br, incrívelmente foi registrado pela mesma pessoa que tem poder sobre os domínios efraimmorais.com.br e efraimorais.com.br.
Agora mais uma, os dois domínios cidados são do website do Senador Efraim Morais, que por acaso, é da Paraiba!
Será apenas coincidência? Realmente, acho que não... mas o pior não chegou, vamos lá:
Temos o site do senado (senado.gov.br), que uma de suas partes é para ser uma área de "transparência de contas", muito legal e foi lá que descobriram isso tudo, parece que funciona.
Porem, alguém muito malandro (ou quase) que trabalha lá ALTEROU OS REGISTROS PÚBLICOS DO SITE, sem deixar nenhuma indicação clara disso, reduzindo o valor do contrato de R$ 48.000 mensal para apenas R$ 48.000 pelo valor total.
Infelizmente, eles esqueceram que nesta era da informática, temos serviços como o cache online do Google, que mantem um histórico de todas as páginas na web.
Caso queiram conferir, aqui esta o cache do Google:
http://209.85.215.104/search?q=cache:jQzY4VgBeRoJ:www.senado.gov.br/sf/contratos/empresaContratada.asp%3Foo=1&e=PARA%CDBA+GRAPHICS+020.559/07-0&hl=pt-BR&ct=clnk&cd=1&gl=br
Aqui está a página atual:
http://www.senado.gov.br/sf/contratos/empresaContratada.asp?o=1&e=PARA%CDBA+INTERNET+GRAPHICS
Realmente, o pessoal está brincando com nosso dinheiro.
Mais uma coisa, ano passado também fizeram um contrato desse, no valor de R$ 40.000 (por mês provavelmente), mas como não descobriram, resolveram por mais um pouco de dinheiro dessa vez:
http://64.233.183.104/search?hl=pt-BR&q=cache%3Awww.senado.gov.br%2Fsf%2Fcontratos%2FempresaContratada.asp%3Fo%3D1%26e%3DPARA%25CDBA%2BGRAPHICS&btnG=Pesquisa+Google&meta=
Se puderem, divulguem aos seus amigos e mostrem que neste tempo onde estão tentando passar leis para criar diversas barreiras ao uso da internet (que ajuda a denunciar as falcatruas realizadas) tem muito mais coisa acontecendo embaixo de nossos narizes.
Recomendo verem este post também:
http://www.meiobit.com/seguranca/maracutaia-no-senado-a-fragilidade-dos-registros-eletronicos
Não sei se vocês estão sabendo, mas esse caso estourou semana passada na internet. Não sei se foi divulgado em jornais, mas muitos blogs e listas de discussões confirmaram isso.
O caso foi o seguinte:
Nossa incrível senado federal, fechou um contrato com o site www.paraiba.com.br, no valor de R$ 48.000 POR MES (R$ 576.000 POR ANO) para colocar um banner de 120x60 px.
Se vocês não tem noção do que é isso, é o tamanho de um botão de OK do windows.
O acesso deste site é MUITO BAIXO, não justificando o pagamento de quantia alguma (ainda mais nesse valor) para uma forma de propaganda.
Mas agora vamos as coincidências...
O domínio paraiba.com.br, incrívelmente foi registrado pela mesma pessoa que tem poder sobre os domínios efraimmorais.com.br e efraimorais.com.br.
Agora mais uma, os dois domínios cidados são do website do Senador Efraim Morais, que por acaso, é da Paraiba!
Será apenas coincidência? Realmente, acho que não... mas o pior não chegou, vamos lá:
Temos o site do senado (senado.gov.br), que uma de suas partes é para ser uma área de "transparência de contas", muito legal e foi lá que descobriram isso tudo, parece que funciona.
Porem, alguém muito malandro (ou quase) que trabalha lá ALTEROU OS REGISTROS PÚBLICOS DO SITE, sem deixar nenhuma indicação clara disso, reduzindo o valor do contrato de R$ 48.000 mensal para apenas R$ 48.000 pelo valor total.
Infelizmente, eles esqueceram que nesta era da informática, temos serviços como o cache online do Google, que mantem um histórico de todas as páginas na web.
Caso queiram conferir, aqui esta o cache do Google:
http://209.85.215.104/search?q=cache:jQzY4VgBeRoJ:www.senado.gov.br/sf/contratos/empresaContratada.asp%3Foo=1&e=PARA%CDBA+GRAPHICS+020.559/07-0&hl=pt-BR&ct=clnk&cd=1&gl=br
Aqui está a página atual:
http://www.senado.gov.br/sf/contratos/empresaContratada.asp?o=1&e=PARA%CDBA+INTERNET+GRAPHICS
Realmente, o pessoal está brincando com nosso dinheiro.
Mais uma coisa, ano passado também fizeram um contrato desse, no valor de R$ 40.000 (por mês provavelmente), mas como não descobriram, resolveram por mais um pouco de dinheiro dessa vez:
http://64.233.183.104/search?hl=pt-BR&q=cache%3Awww.senado.gov.br%2Fsf%2Fcontratos%2FempresaContratada.asp%3Fo%3D1%26e%3DPARA%25CDBA%2BGRAPHICS&btnG=Pesquisa+Google&meta=
Se puderem, divulguem aos seus amigos e mostrem que neste tempo onde estão tentando passar leis para criar diversas barreiras ao uso da internet (que ajuda a denunciar as falcatruas realizadas) tem muito mais coisa acontecendo embaixo de nossos narizes.
Recomendo verem este post também:
http://www.meiobit.com/seguranca/maracutaia-no-senado-a-fragilidade-dos-registros-eletronicos
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)
Assinar:
Postagens (Atom)