SysThoughts

Essa é uma otima dica para quem possui um HDD Híbrido para notebooks , no caso o Seagate Momentus XT

Híbrido? WTH is that?

Os modelos de notebook normalmente vem com dois tipos de HDDs, os de disco magnético (bastante espaço de armazenamento, pouco performatico, seek time bem alto ainda mais se levarmos em conta que a maioria dos notebooks vem com HDDs de 5400 rpm) e os de estado solido (SSD – Solid State Drive , pouco espaço de armazenamento, altamente performatico e seek time bem baixo) como a Série Vertex 2 da OCZ , o grande problema nesse caso é o preço desses SSDs, ainda mais no Brasil. Ano passado eu acabei esbarrando com uma noticia que a Seagate tinha lançado HDDs hibridos para uso em notebooks, esses discos nada mais são como os que ja conhecemos porem com uma camada de SSD adaptativa para uso em leitura dos blocos mais acessados , resolvi arriscar e comprei para meu MacBook Pro.
Essa parte adaptativa do HDD (chamada pela Seagate de Adaptative Memory tecnology) nada mais é que um “sistema” que monitora os blocos mais acessados por ele , tal como documentos, imagens, aplicações que voce mais utiliza e os coloca tambem nesse componente SSD para que a leitura seja muito mais rapida, porem ele não faz a escrita no SSD, apenas a leitura.

Velocidade

Desde que comecei a utilizar esse HDD não tive o que reclamar na questão da velocidade, bem rapido, ainda mais pelo fato de ser um HD de 7200 rpm e ter 32MB de cache que por si so ja faz uma diferença grande diante dos HDDs padrão da apple de 5400 rpm, senti bastante diferença na hora de subir uma VM no Parallels, assim como fazer freeze dela e tambem resume, porem sempre notava que de tempos em tempos parecia que o HD tinha parado e fazia um barulho como se estivesse religando novamente (com um apito meio baixo), ainda mais pelo fato de não notar que o HDD utilizasse de fato a camada SSD dele tanto quanto eu notava estar sendo utilizado em alguns momentos.

Firmware

Essa dica veio do Gleicon que acabou gravando um CD para a atualização do HDD dele e acabou passando ja para eu testar tambem. Essa ISO vem com uma imagem do FreeDOS que boota um pequeno utilitário da Seagate com algumas opções tais como listar os HDDs da maquina, qual versão do firmware que esta no seu HDD , e tambem claro a opção de atualizar o fw do seu HDD, o processo é bem rapido , no meu caso demorou menos de 20 segundos a atualização e depois so é necessario desligar o notebook e ligar novamente para fazer os primeiros testes. Lembrando que o primeiro boot depois dessa atualização é um pouco demorado mesmo, isso parece ser um comportamento esperado, os proximos boots são muito mais rapidos.
Acredito também que a maior parte dos momentos lançados pela Seagate vem com a versão SD23 instalada (foi o meu caso e de 2 amigos que tem esse mesmo modelo).

Modelos suportados:
ST92505610AS
ST93205620AS
ST95005620AS

Conclusão

Para quem ja possui esse disco e ainda não fez a atualização , eu recomendo fortemente , fez uma diferença absurda na performance do meu notebook e tambem de outros amigos que tambem utilizam , não so na questão do uso da SSD adaptativo mas tambem na propria escrita do disco que eu acho que esta mais rapida tambem.
Para quem pensa em comprar o HDD depois de instalado antes mesmo de usar ja realize esse update !

Apenas uma pequena noticia para todos os usuários da distro, ja esta disponivel a iso[1] multi-arch do release Squeeze, uma mão na roda se voce precisa instalar ainda ambientes 32bits sem ter que manter varios ISOs diferentes

[1]: http://cdimage.debian.org/debian-cd/6.0.0/multi-arch/iso-cd/

Depois que escrevi o post relacionado aos arquivos presos por um processo o Cassiano passou uma dica muito boa que vale um blog post!

Cenário

Voce esta logado em um servidor remotamente via SSH, e por algum motivo bizarro , ou sem motivo ou por pura falta de atenção voce acaba removendo o Bash do servidor, voce abre um novo terminal ou uma outra pessoa tenta logar neste mesmo servidor e ocorre essa mensagem de erro:

dezoris:~ ferraz$ ssh 192.168.1.110
Last login: Sat Jan 22 01:53:45 2011 from 192.168.1.4
/bin/bash: No such file or directory
Shared connection to 192.168.1.110 closed.

Quando ocorrer esse problema se voce ainda estiver conectado à maquina não precisa entrar em desespero e também não precisa reinstalar o pacote do Bash novamente, vamos utilizar o recurso da partição /proc montada neste server , inicialmente precisariamos saber qual é o pid do processo Bash que estamos utilizando , podemos pegar essa informação executando um echo $$ so que desta vez não tem a necessidade de se verificar o PID do processo bash para localizar as informações necessarias em /proc, basta acessar o diretorio /proc/self, self é um link simbolico que aponta para o processo em execução no momento, no caso é a shell que mantemos aberta.
Lembrando que dentro do diretorio /proc/self vamos encontrar diversas informações sobre a shell em execução armazenada em arquivos, symlinks ou diretorios. A parte que nos interessa é o symlink chamado exe no qual aponta para o PATH do processo do qual aquelas informações do diretorio proc fazem parte:

root@delorean:/proc/self# ls -lah exe
lrwxrwxrwx 1 root root 0 2011-01-22 01:54 exe -> /bin/bash (deleted)

Conforme mostrado no ultimo post, a informação extra (deleted) informa que a shell que mantemos ainda aberta em execução esta segurando o conteudo do executavel bash em memória , com isso podemos fazer o seguinte:

root@delorean:/proc/self# cp exe /bin/bash
root@delorean:/proc/self# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

Se tentarmos logar no server de outro terminal conseguiremos acesso!

dezoris:~ ferraz$ ssh 192.168.1.110
Last login: Sat Jan 22 01:58:16 2011 from 192.168.1.4
ferraz@delorean:~$

O que aconteceu?

Como mantinhamos a Shell ainda em execução o symlink continuava à apontar para o executavel mesmo depois de deletado com isso temos a possibilidade de fazer uma copia do conteudo que o symlink apontava novamente para o PATH original. Lembrando que o foi feito foi apenas a recuperação do conteudo do executável, não foi recuperado por si o arquivo original, se listarmos o symlink exe depois da copia veremos a informação de arquivo deletado ainda lá:

ferraz@delorean:/proc/self$ ls -lah exe
lrwxrwxrwx 1 ferraz ferraz 0 2011-01-22 02:22 exe -> /bin/bash (deleted)

Isso acontece porque o symlink ainda aponta para o inode do antigo Bash que foi removido, quando voce fez uma copia do conteudo que exe aponta foi criado um novo inode que aponta para esse novo executavel:

root@delorean:/proc/1090# ls -li /bin/bash
130861 -rwxr-xr-x 1 root root 934336 2011-01-22 02:17 /bin/bash
root@delorean:/proc/1090# rm /bin/bash
root@delorean:/proc/1090# ls -lah exe
lrwxrwxrwx 1 ferraz ferraz 0 2011-01-22 02:22 exe -> /bin/bash (deleted)
root@delorean:/proc/1090# cp exe /bin/bash
root@delorean:/proc/1090# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
root@delorean:/proc/1090# ls -li /bin/bash
130862 -rwxr-xr-x 1 root root 934336 2011-01-22 02:26 /bin/bash

Lembrando que essa dica apenas funciona se voce mantem uma Shell aberta no servidor no momento da remoção, se o bash foi removido e voce deslogou do servidor ou se executou um script remotamente via SSH voce nao tem mais a informação do processo via /proc disponivel para o restore.

Cenário

O cenário é conhecido , voce tem um ambiente com espaço em disco baixo e o volume da partição de logs esta quase cheio , voce verifica que tem um arquivo de log ocupando bastante espaço:

ahfalo:/var/log# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                       38G   26G   11G  71% /
tmpfs                 2.0G  4.0K  2.0G   1% /lib/init/rw
udev                  2.0G  216K  2.0G   1% /dev
tmpfs                 2.0G  624K  2.0G   1% /dev/shm
/dev/sda1             274M  134M  127M  52% /boot
/dev/mapper/VolGroup00-tmp
                      5.6G  614M  4.7G  12% /tmp
/dev/mapper/VolGroup00-var
                       56G   48G  5.2G  91% /var
/dev/mapper/VolGroup01-chroot
                       82G   60G   19G  77% /var/chroots

ferraz@ahfalo:~$ ls -lah /var/log/daemonlog
-rw-r--r-- 1 root root 10G 2010-12-11 01:19 /var/log/daemonlog

Até ae sem novidades, voce remove o arquivo e verifica novamente o espaço em disco disponivel:

ahfalo:/var/log# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                       38G   26G   11G  71% /
tmpfs                 2.0G  4.0K  2.0G   1% /lib/init/rw
udev                  2.0G  216K  2.0G   1% /dev
tmpfs                 2.0G  624K  2.0G   1% /dev/shm
/dev/sda1             274M  134M  127M  52% /boot
/dev/mapper/VolGroup00-tmp
                      5.6G  614M  4.7G  12% /tmp
/dev/mapper/VolGroup00-var
                       56G   48G  5.2G  91% /var
/dev/mapper/VolGroup01-chroot
                       82G   60G   19G  77% /var/chroots

O que aconteceu ?

Nesse momento fica a duvida porque o espaço em disco não foi liberado , voce executa o lsof para analisar os arquivos que estão abertos pelo processo do Daemon e encontra esse caso:

root@ahfalo:~# lsof -p 14567

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
mydaemon 14567 root  cwd    DIR    8,2     4096  65409 /root
mydaemon 14567 root  rtd    DIR    8,2     4096      2 /
mydaemon 14567 root  txt    REG    8,2  2279976   3799 /usr/bin/python2.6
mydaemon 14567 root  mem    REG    8,2     9736    143 /lib/libdl-2.12.1.so
mydaemon 14567 root  mem    REG    8,2     9748   4068 /lib/libutil-2.12.1.so
mydaemon 14567 root  mem    REG    8,2   121578    824 /lib/libpthread-2.12.1.so
mydaemon 14567 root  mem    REG    8,2  1353652   4282 /lib/libcrypto.so.0.9.8
mydaemon 14567 root  mem    REG    8,2   149392    152 /lib/libm-2.12.1.so
mydaemon 14567 root  mem    REG    8,2  1421892    134 /lib/libc-2.12.1.so
mydaemon 14567 root  mem    REG    8,2   294696   4281 /lib/libssl.so.0.9.8
mydaemon 14567 root  mem    REG    8,2    79476    119 /lib/libz.so.1.2.3.4
mydaemon 14567 root  mem    REG    8,2   118084    120 /lib/ld-2.12.1.so
mydaemon 14567 root  mem    REG    8,2  2768240 155207 /usr/lib/locale/locale-archive
mydaemon 14567 root    0u   CHR  136,0      0t0      3 /dev/pts/0
mydaemon 14567 root    1u   CHR  136,0      0t0      3 /dev/pts/0
mydaemon 14567 root    2u   CHR  136,0      0t0      3 /dev/pts/0
mydaemon 14567 root    3w   REG    8,2     1060 131921 /var/log/daemon.log (deleted)

O que importa para nos é essa ultima linha:

mydaemon 14567 root    3w   REG    8,2     1060 131921 /var/log/daemon.log (deleted)

O lsof esta informando que o processo mydaemon com o pid 15567 esta com o arquivo daemon.log aberto em modo de escrita (w) , muitas vezes a aplicação precisa realmente estar com o arquivo aberto durante o tempo todo para poder escrever alguma informação , por isso que o lsof esta exibindo o status deleted, pois o processo esta ainda com o arquivo aberto, nesse caso podemos reiniciar o daemon para que ele possa liberar esse File Descriptor e o SO possa liberar o espaço que o antigo arquivo de log estava consumindo.

O problema é muitas vezes não podemos reiniciar o Daemon naquele momento, o que podemos fazer então?

/proc Filesystem

Dentro do ambiente Linux, quando o Linux é inicializado alem das partições em disco e de rede que montamos existem algumas partições virtuais que o sistema monta, uma delas é o procfs , dentro desse filesystem podemos pegar muitas informações sobre o que esta sendo executado no seu ambiente , e mais ainda sobre um PID específico. Se usarmos como exemplo o PID do nosso daemon de exemplo (pid 14567):

root@urubu:~# ls -lah /proc/14567
total 0
dr-xr-xr-x   7 root root 0 2010-12-12 16:12 .
dr-xr-xr-x 163 root root 0 2010-12-01 01:42 ..
dr-xr-xr-x   2 root root 0 2010-12-12 16:39 attr
-r--------   1 root root 0 2010-12-12 16:39 auxv
-r--r--r--   1 root root 0 2010-12-12 16:39 cgroup
--w-------   1 root root 0 2010-12-12 16:39 clear_refs
-r--r--r--   1 root root 0 2010-12-12 16:12 cmdline
-rw-r--r--   1 root root 0 2010-12-12 16:39 comm
-rw-r--r--   1 root root 0 2010-12-12 16:39 coredump_filter
-r--r--r--   1 root root 0 2010-12-12 16:39 cpuset
lrwxrwxrwx   1 root root 0 2010-12-12 16:16 cwd -> /root
-r--------   1 root root 0 2010-12-12 16:39 environ
lrwxrwxrwx   1 root root 0 2010-12-12 16:16 exe -> /usr/bin/python2.6
dr-x------   2 root root 0 2010-12-12 16:12 fd
dr-x------   2 root root 0 2010-12-12 16:16 fdinfo
-r--r--r--   1 root root 0 2010-12-12 16:39 io
-r--r--r--   1 root root 0 2010-12-12 16:39 latency
-r--------   1 root root 0 2010-12-12 16:39 limits
-rw-r--r--   1 root root 0 2010-12-12 16:39 loginuid
-r--r--r--   1 root root 0 2010-12-12 16:16 maps
-rw-------   1 root root 0 2010-12-12 16:39 mem
-r--r--r--   1 root root 0 2010-12-12 16:39 mountinfo
-r--r--r--   1 root root 0 2010-12-12 16:39 mounts
-r--------   1 root root 0 2010-12-12 16:39 mountstats
dr-xr-xr-x   5 root root 0 2010-12-12 16:39 net
-rw-r--r--   1 root root 0 2010-12-12 16:39 oom_adj
-r--r--r--   1 root root 0 2010-12-12 16:39 oom_score
-r--------   1 root root 0 2010-12-12 16:39 pagemap
-r--------   1 root root 0 2010-12-12 16:39 personality
lrwxrwxrwx   1 root root 0 2010-12-12 16:16 root -> /
-rw-r--r--   1 root root 0 2010-12-12 16:39 sched
-r--r--r--   1 root root 0 2010-12-12 16:39 schedstat
-r--r--r--   1 root root 0 2010-12-12 16:39 sessionid
-r--r--r--   1 root root 0 2010-12-12 16:39 smaps
-r--------   1 root root 0 2010-12-12 16:39 stack
-r--r--r--   1 root root 0 2010-12-12 16:12 stat
-r--r--r--   1 root root 0 2010-12-12 16:39 statm
-r--r--r--   1 root root 0 2010-12-12 16:12 status
-r--------   1 root root 0 2010-12-12 16:39 syscall
dr-xr-xr-x   3 root root 0 2010-12-12 16:39 task
-r--r--r--   1 root root 0 2010-12-12 16:39 wchan

Dentro de cada arquivo ou diretorio temos uma serie de informações desse processo relacionado ao SO , um desses diretorios é o fd:

root@urubu:~# ls -lah /proc/14567/fd
total 0
dr-x------ 2 root root  0 2010-12-12 16:12 .
dr-xr-xr-x 7 root root  0 2010-12-12 16:12 ..
lrwx------ 1 root root 64 2010-12-12 16:13 0 -> /dev/pts/0
lrwx------ 1 root root 64 2010-12-12 16:13 1 -> /dev/pts/0
lrwx------ 1 root root 64 2010-12-12 16:13 2 -> /dev/pts/0
l-wx------ 1 root root 64 2010-12-12 16:13 3 -> /var/log/daemon.log (deleted)

A partir dessa informação podemos realmente liberar o espaço em disco, lembrando que não podemos remover o file descriptor, apenas truncar a informação do arquivo

root@ahfalo:~# cd /proc/14567/fd
root@ahfalo:~# > 3

Ou podemos abrir o arquivo em modo de escrita :

ahfalo:/proc/14567/fd# python
Python 2.6.6 (r266:84292, Dec 12 2010, 15:15:09)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open("3","w")
<open file '3', mode 'w' at 0x7fb77d428c90>

Depois que realizamos um desses procedimentos agora sim o espaço foi liberado:

ahfalo:/var/log# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                       38G   26G   11G  71% /
tmpfs                 2.0G  4.0K  2.0G   1% /lib/init/rw
udev                  2.0G  216K  2.0G   1% /dev
tmpfs                 2.0G  624K  2.0G   1% /dev/shm
/dev/sda1             274M  134M  127M  52% /boot
/dev/mapper/VolGroup00-tmp
                      5.6G  614M  4.7G  12% /tmp
/dev/mapper/VolGroup00-var
                       56G   38G   16G  72% /var
/dev/mapper/VolGroup01-chroot
                       82G   60G   19G  77% /var/chroots

Esse é um cenário relativamente comum, alguns daemons deixam o fd aberto e não possuem um processo de receber algum sinal via kill e reabrir os arquivos de log ou similares, então nessa situação em vez de remover o arquivo e ter que trunca-lo e ter que reiniciar o processo mais tarde para poder ter um novo arquivo de log apenas trunque o arquivo quando estiver ocupando muito espaço em disco, assim voce reutiliza o arquivo ja aberto pelo processo para continuar a escrever nele

OBS: nos testes que realizei via Ubuntu o procedimento de truncar via shell com “> 3″ não funcionou, ainda não tenho certeza o que pode ser , imaginei que fosse algo relacionado ao ext4 e o flush em disco mas eu não consegui reproduzir numa vm Fedora que tenho com ext4 também, logo que tiver maiores informações posto um update.

Durante esse sabado participei da ffffuuuu.conf na Caelum que cedeu o espaco e foi organizada pelo Renato Lucindo, essa conferencia foi bem descontraida porem com um conteudo muito bom .  O que achei diferente foi o fato de apresentar informações sensatas sobre a realidade do ambiente de trabalho ligado a assuntos como programacao e metodos Ageis, muitas apresentações em outras conferencias ou artigos em blogs acabando mostrando que determinado assunto (seja uma tecnologia ou uma metodologia) é a solução de todos nossos problemas , o que não é verdade, sempre existe um uso para um fim especifico e suas exceções .

Espero que a conferencia tenha uma nova versão o que acredito que vai acontecer pela repercussao entre as pessoas que participaram .

Seguem os slides de algumas das palestras, as palestras foram gravadas , quando tiver disponiveis tentarem postar os links no site

Patterns of Fail – Gleicon Moraes – @gleicon

Agile or Fragile – Rodrigo Campos – @xinu

Itil for Failers – Roberto Gaiser – @rgaiser

You shall not get Excited – Ivan Ribeiro Rocha – @irr

How Not To Use The Right Tool For The Wrong Reason – Fabio Trentini – @trentas

Software Instability – Renato Lucindo – @rlucindo

How to Crap – John D. Rowell – @jdrowell

Apresentacao

A equipe responsável pelos releases do Debian 5.0 codinome Lenny realizou uma nova atualização da distribuição levando à versão 5.0.6 , essa atualização é focada apenas em trazer as correções de segurança para o repositório principal de instalação assim como outros bugfixes , as imagens de instalação ainda estão sendo geradas e estarão disponíveis logo

Correções de Segurança incluidas nesta versão

DSA-1919 smarty Regression in previous update
DSA-2054 bind9 Cache poisoning
DSA-2059 pcsc-lite Regression
DSA-2064 xulrunner Several vulnerabilities
DSA-2065 kvirc Several vulnerabilities
DSA-2066 wireshark Several vulnerabilities
DSA-2067 mahara Several vulnerabilities
DSA-2068 python-cjson Denial of service
DSA-2069 znc Denial of service
DSA-2070 freetype Several vulnerabilities
DSA-2071 libmikmod Several vulnerabilities
DSA-2072 libpng Several vulnerabilities
DSA-2073 mlmmj Directory traversal
DSA-2074 ncompress Arbitrary code execution
DSA-2075 xulrunner Several vulnerabilities
DSA-2076 gnupg2 Execution of arbitrary code
DSA-2078 kvirc Arbitrary IRC command execution
DSA-2078 mapserver Arbitrary code execution
DSA-2080 ghostscript Several vulnerabilities
DSA-2081 libmikmod Arbitrary code execution
DSA-2082 gmime2.2 Arbitrary code execution
DSA-2083 moin Cross-site scripting
DSA-2084 tiff Arbitrary code execution
DSA-2085 lftp File overwrite vulnerability
DSA-2086 avahi Denial of service
DSA-2087 cabextract Arbitrary code execution
DSA-2088 wget Potential code execution
DSA-2089 php5 Several vulnerabilities
DSA-2090 socat Arbitrary code execution
DSA-2091 squirrelmail Cross-site request forgery
DSA-2092 lxr-cvs Cross-site scripting
DSA-2093 ghostscript Several vulnerabilities
DSA-2094 linux-2.6 Several issues
DSA-2094 user-mode-linux Several issues
DSA-2095 lvm2 Denial of service
DSA-2096 zope-ldapuserfolder Authentication
DSA-2097 phpmyadmin Several vulnerabilities
DSA-2098 typo3-src Several vulnerabilities
DSA-2099 openoffice.org Arbitrary code execution
DSA-2100 openssl Double free
DSA-2101 wireshark Several vulnerabilities

Fonte e Maiores informações: http://www.debian-news.net/2010/09/05/debian-gnulinux-5-0-updated-5/

Enquanto o release Squeeze ainda se encontra em processo de freeze ,  com o foco em correções de bugs críticos , atualizações de traduções e correções na documentação dos programas, ja foi decidido [1] qual será o codinome da versão 7.0 do Debian que será Wheezy , o pinguim de gravata vermelha que aparece apenas em Toy Story 2

Apesar do release Squeeze não ter sido lançado ainda espero que esta próxima versão venha mais rapidamente do que as anteriores

[1] http://lists.debian.org/debian-devel-announce/2010/09/msg00000.html
Fonte: http://www.h-online.com/open/news/item/Debian-7-0-named-1072569.html

Durante a Debconf 10 em New York , foi decidido que o proximo release codinome Squeeze irá entrar em processo de freeze

O que isto significa?

Dentro do conceito de repositorios Debian, existem 3 “branches” principais: stable , testing , unstable , sendo que todo release stable possui um codinome, nessa versão é o Squeeze:

Todos os releases da distribuição tem seus codinomes vindos de personagens do filme Toy Story da Pixar , sendo os antigos releases os seguintes nomes:

• Buzz – Debian 1.1
• Rex – Debian 1.2
• Bo – Debian 1.3
• Hamm – Debian 2.0
• Slink – Debian 2.1
• Potato – Debian 2.2
• Woody – Debian 3.0
• Sarge – Debian 3.1
• Etch – Debian 4.0
• Lenny – Debian 5.0

Lembrando que o Branch unstable sempre terá o codinome SID (O vizinho que sempre destruía os brinquedos na animação)

Quando um mantenedor/desenvolvedor precisa fazer um upload de uma nova versão de um pacote ou de um novo pacote na distribuição isso é feito dentro de uma fila chamada de incoming, se o pacote estiver assinado corrertamente e estiver conforme os guidelines Debian será enviado ao pool de pacotes aonde sera sincronizado entre todos os mirrors existentes e apartir dai estará disponivel no repositorio unstable , a partir deste branch se o pacote não tiver um numero de bugs criticos maior que o mesmo pacote que esta no repositorio testing, estiver compilado com sucesso em todas as arquiteturas que a distribuição suporta dentre outras dependencias este pacote será incluido no repositorio testing que é o “branch” oficial para as proximas versões stable, ou seja durante todo esse tempo teremos todo um ciclo de inclusão de novas versões de pacotes entre esses repositorios acontecendo até que o Release Manager da distribuição indique que o repositório entre no processo de freeze, com isso não serão aceitas novas versões de pacotes vindos do “branch” unstable e sim apenas correções dos pacotes que existem na testing, garantindo que todos os bugs criticos que encontram-se abertos estejam corrigidos

O processo completo de vida de um pacote no ambiente Debian é bem mais complexo que isso, simplifiquei o processo apenas para a parte principal, não incluindo o processo de updates de segurança, pacotes voláteis dentre outros casos conforme diagrama abaixo

Dentro do plano de verificação de bugs RC (Release Critical) o último levantamento trouxe a informação de 220 bugs criticos que devem ser resolvidos para que ae sim o release 6.0 Squezee se torne a proxima versão Stable do Debian

Entre as principais inclusões nesta versão estão o uso do kernel 2.6.32,  Gnome 2.30, KDE 4.4.5, XFCE 4.6.2, o uso dos interpredatores Perl 5.10, Python 2.6 (Finally !!) e GCC na versão 4.4, utilização do insserv trazendo ordem de dependencia entre scripts init podendo ser executado em paralelo com uma maior velocidade no boot, assim como a inclusão do uso de kernel FreeBSD para esta versão utilizando o userland gnu ao invés do BSD

A partir de agora então o foco do time Debian esta em resolver esses bugs, e para ajudar nessa area acontecerão Bug Squashing Parties no canal #Debian-Bugs na rede de irc da OFTC , tentarei acompanhar mais o status de como anda o progresso do processo de freezing mantendo atualizado com informações aqui no blog, até a proxima!