Caixa Seca

Hoje temos Fedora, openSUSE e Mandriva usando o systemd como init padrão. Agora, o Mageia entrou na lista. Colin Guthrie, hacker do PulseAudio e desenvolvedor da distribuição, junto com Dexter Morgan, está fazendo as adaptações para o fork do Mandriva usar o systemd em sua próxima versão (Mageia 2). A mudança está envolvendo também a migração para o Dracut como gerador de initramfs, para uma melhor integração com o systemd. No caminho, Colin fez algumas correções no Dracut, que foram comunicadas ao upstream. Assim que software livre funciona. Além de Lennart Poettering, Kay Sievers, Michal Schmidt (Red Hat), o mesmo faz (ou fez) Frederic Crozat (openSUSE), Tom Gundersen (Arch), Andrey Borzenkov (Mandriva), Miklos Vajna (Frugalware), Tollef Fog Heen (Debian), entre outros. Um trabalho em equipe. O começo para desfazer a anarquia. Para modernizar e uniformizar o encanamento. Até mesmo o Debian terá o systemd como opção no Wheezy ao que tudo indica! Por padrão é meio difícil, visto que

Seagate completes buyout of Samsung's HDD business (The Tech Report) Ai, ai, ai. 2000: Maxtor compra Quantum . 2003: Hitachi compra IBM . 2006: Seagate compra Maxtor . 2011: Western Digital compra Hitachi . 2011: Seagate compra Samsung . (entenda-se compra da divisão de HDDs de cada fabricante citado) Temos então dois grandes fabricantes ainda de pé: Western Digital e Seagate.

No dia 18 de janeiro de 2011, um grupo de programadores insatisfeitos com a liderança de Michael Niedermayer tomou o controle do FFmpeg e mudou o repositório de endereço. A alegação dos insurgentes era que Niedermayer não estava cumprindo seu papel de líder e mantenedor do projeto, pois não possuía a diplomacia necessária para o trabalho e rejeitava patches por picuinhas e diferenças pessoais. No começo, se falava em "mudança de liderança", mas com o passar do tempo — pelo menos com o que foi possível obter das discussões públicas sobre o acontecido — o termo correto passou a ser golpe. A trama foi feita na surdina e Niedermayer sofreu uma rasteira. Por mais inepto que fosse para o cargo, tudo deveria ter sido público, até mesmo para dar legitimidade caso fosse realmente necessário tirá-lo na marra. Só que os insurgentes não contavam que o dono do domínio ffmpeg.org (Fabrice Bellard, criador do projeto) devolveria o controle do mesmo para Michael Niedermayer, que junto co

Hahahaha. Os integradores nacionais sempre inovando! Um tal de "Megalinux" vem até com um script autodestrutivo: Remove.sh gksu ls zenity --warning --text="Esse script ira limpar COMPLETAMENTE todas as informações contidas em seu computador! Antes de executar o script remova pendrive, celular, ou qualquer outro dispositivo de armazenamento que esteja conectado em seu computador." zenity --question --title="Tem certeza que deseja executar o script?" || exit 11 DISKS=$( sudo fdisk -l | grep /dev | cut -f1 -d " " | grep dev| cut -b 1-8 | uniq) for disks in $DISKS; do gksu "dd if=/dev/zero of=$DISKS bs=512 count=1" done Hahahaha. dd if=/dev/zero of=$DISKS bs=512 count=1 com o sistema rodando, que maravilha! Quem não tiver nada para fazer, experimente detonar uma instalação de teste com esse método. É mais bruto que rm -rf / , pois o rm pelo menos tem uma proteção que impede remoção acidental do diretório raiz. O problema (o

Pois bem. Na lista de discussão do XFS, ontem, deu as caras um post comentando o impacto do uso da opção de montagem discard com dois SSDs, um OCZ Agility 3 (SandForce 2281) e outro Corsair Performance Pro (Marvell 88SS9174) rodando Linux 3.2-rc5. No OCZ, a opção discard degrada demais o desempenho. Enquanto no Corsair não. Com EXT4, por outro lado, os dois SSDs são rápidos. Dave Chinner, um dos principais desenvolvedores do XFS, diz que para consertar o comportamento (de enviar cada despacho serial e sincronamente), além do código do XFS, o VFS do kernel provavelmente precise ser modificado — ele não comenta o que o EXT4 faz para enviar as requisições em blocos, contudo. Sua recomendação é não usar a opção de montagem discard no XFS por enquanto. Referência: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/42407/focus=42411

Continuando no assunto de partições, alinhamento, SSDs, Linux, 4KiB, o escambau. :-) O parted consulta a libblkid para obter a topologia do disco. Com ele, você pode conferir se o particionamento está alinhado corretamente. Útil para HDs com setores físicos de 4KiB e SSDs. Rode no terminal: # parted -l Isso mostrará uma lista com as partições do disco, como por exemplo: Modelo: ATA SAMSUNG HM160HI (scsi) Disco /dev/sda: 160GB Tamanho de setor (lógico / Físico): 512B/512B Tabela de Partição: msdos Número Início Fim Tamanho Tipo Sistema de arquivos Sinalizador 1 1049kB 15,4GB 15,4GB primary ext4 boot 2 15,4GB 160GB 145GB primary ext4 Veja o nome do dispositivo na linha "Disco /dev/sda : 160GB" e, da coluna "Número", pegue cada número e rode esse comando para verificar o alinhamento: # parted /dev/sda -- align-check optimal 1 O comando retornará algo como: 1 alinhado que significa que a partição &qu

Levando em conta que o NTFS, no Windows 8, usará clusters de 4 KiB sem usar a camada de emulação (512e) nos HDDs com "Advanced Format" e SSDs, este post é uma atualização do Suporte ao comando ATA TRIM no Linux . O que postei em Usando o GParted com o Parted Magic e Ubuntu 10.04 saberá lidar com HDs com setores de 4KiB também continua valendo; ou seja, para começar, é necessário ter as partições corretamente alinhadas, o que felizmente não é mais problema, visto que os instaladores (pelo menos das distribuições maiores) estão adaptados. Como o Linux possui vários sistemas de arquivos, falarei apenas dos que possuem relevância: EXT4 e XFS (Btrfs deixo de lado pois é experimental). O mke2fs da suíte e2fsprogs automaticamente ajusta o tamanho de cada bloco de acordo com o tamanho do setor físico do dispositivo. Portanto, em teoria™, é tudo automático com EXT4. Já com XFS, para usar os setores de 4 KiB sem emulação, na hora da criação do sistema de arquivos, o mkfs.xfs

A partir do Windows Vista, as ferramentas de particionamento do sistema operacional foram adaptadas para o novo alinhamento, como comentado em Usando o GParted com o Parted Magic e Ubuntu 10.04 saberá lidar com HDs com setores de 4KiB . Assim, o desempenho não é comprometido em HDs com setores físicos de 4KiB e SSDs. Contudo, o sistema continuou usando os setores emulados de 512 bytes ("512e") para comunicar-se com o dispositivo. Para o Windows 8, a Microsoft tem algumas novidades: Enabling large disks and large sectors in Windows 8 (Building Windows 8) A principal delas é que o encanamento do NTFS foi modificado para lidar com os setores físicos de 4KiB nativamente , sem usar a camada de emulação 512e, quando suportado pelo dispositivo. E foram feitos melhoramentos na API disponível para aplicações consultarem o tamanho físico dos setores. Lembrando que no Windows 7 o sistema passou a usar o comando TRIM dos SSDs (ver Suporte ao comando ATA TRIM no Linux ).

A ferramenta de linha de comando ffmpeg é bastante útil para conversões diversas e para gravar áudio e vídeo a partir dos dispositivos da máquina. A configuração fina de cada codec é meio complicada (com exceção da libx264 ), mas depois de aprendido é tranquilo. As versões recentes possuem duas novidades importantes: suporte para entrada via DirectShow no Windows e PulseAudio no Linux. PulseAudio Vamos começar pelo dispositivo de entrada "pulse", que permite capturar áudio usando a libpulse. ffmpeg -f pulse -i default <resto> Em <resto> você completa com as demais configurações, como tipo de codec, bitrate e arquivo de saída. Algo como: ffmpeg -f pulse -i default -c:a libvorbis -b:a 128k audio.ogg Se você quiser modificar os parâmetros que o FFmpeg requesitará para a libpulse, existem opções para este fim, como -channels e -sample_rate (veja mais aqui ). A biblioteca fará as modificações necessárias automaticamente (reamostragem e downmix) quando

Foi lançada ontem a versão 1.3.14, que dá mais um passo rumo à versão 2.0 final, que se aproxima (ou não...). Apesar do "Beta", é a versão recomendada, principalmente para usuários do Windows Vista/7 e Mac OS X 10.6/10.7, pois a versão "estável", 1.2.6, é velha demais, possui problemas de compatibilidade com estes sistemas e não está mais em ativo desenvolvimento. A versão 2.0, que se originará da 1.3 Beta, será a última a ter suporte a Windows 98/ME. Versões posteriores exigirão no mínimo Windows 2000. Estão disponíveis na página do projeto compilações prontas para Mac OS X 10.4 e posteriores (Intel/PPC), para Windows 98/ME (!), 2000/XP/Vista/7, além do código fonte. http://audacity.sourceforge.net/ Changelog da versão: 2. Changes in version 1.3.14 Beta: Bug fixes for: * Interface: * Excessive delay occurred when typing into labels in long projects. * Last digit of TimeText controls could not be manipulated in some formats. * (Windows, OS X

Firefox is bursting at the seams (The H) que linka Gecko Is Too Big (Or, Why the Tree Is Closed) Esta é uma notícia interessante. A Mozilla está com dificuldade para compilar o Firefox 32-bit para Windows porque o linker do MSVC fica sem memória suficiente por causa do limite de 3GB por aplicação dos Windows 32-bit (inicialmente 2GB, mas que pode ser expandido com a chave /3GB no BCD ). As alternativas são: - Fazer compilações sem PGO, o que resultaria em perda de desempenho nos binários gerados, mas aliviaria a quantidade de memória requerida durante a compilação. - Exugar a libxul, movendo o que for possível para bibliotecas separadas. - Compilar a versão 32-bit dentro de um Windows 64-bit, onde o limite por aplicação 32-bit são 4GB completos. - Migrar para o MSVC10, que consome menos memória. Todas as opções podem acabar em enxugação de gelo se a libxul não entrar num regime permanente, pois o atual limite de 3GB ou 4GB daqui algum tempo pode voltar a ser problema, co

O Kraftwerk recomendou um tal de "Free AAC Converter" no FGdH. Eu fiquei curioso, pois os dois encoders AAC open source mais populares — o FAAC e a libavcodec (ffaac) — são tenebrosos. Horríveis. Instalei o referido programa e adianto que ele provavelmente use a libavcodec para gerar AAC. A propóstito, os trambiqueiros que desenvolvem esse programa estão violando a GPL, ou LGPL, dependendo das configurações que usaram para compilar o FFmpeg/Libav, pois não existe menção nenhuma sobre o uso das suas bibliotecas, nem muito menos o código fonte — do programa inteiro, no caso da GPL, ou do FFmpeg/Libav apenas, no caso da LGPL —, que eles são obrigados a disponibilizar. E deveriam fazer o usuário concordar com a GPL/LGPL na hora da instalação do programa também, o que não fazem. Mais um para o Hall of Shame . Na pasta do programa em "C:\Arquivos de Programas": | free-aac-converter-license.txt | free-aac-converter.exe | unins000.dat | unins000.exe | web

Com o advento do Gnome 3 e do KDE 4, surgiram os dois forks com a meta de manter as versões anteriores "vivas". Vivas entre aspas pois são mal-e-mal mantidas, se é que manutenção de um ambiente complexo por uma pessoa pode ser chamada desta forma... A situação dos ambientes gráficos é a seguinte: Gnome 3/KDE 4: ambientes que são efetivamente desenvolvidos e mantidos. XFCE: dos ambientes "leves", foi o que mais conseguiu progredir, porém seu desenvolvimento está lento. O port para GTK3 não deve sair antes do XFCE 4.12 e, levando em conta o andar da carruagem, deve demorar... MATE/Trinity DE: na prática não mantidos; dependem de pilhas e pilhas de bibliotecas obsoletas; mortos. Assunto tirado do seguinte tópico da lista de discussão fedora-devel: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/157317

Windows NT versus Windows 95 e Windows 98 Windows NT e Windows 95 (e sua versão seguinte, o Windows 98) fazem parte da "família Windows de sistemas operacionais", compartilhando um subconjunto comum da API (Win32 e COM), modelo de driver de dispositivo (WDM) e em alguns casos um código compartilhado do sistema operacional. Embora o Windows NT 4.0 não tenha alguns dos recursos que o Windows 95 possui atualmente, a Microsoft sempre deixou claro que o Windows NT seria uma plataforma de sistema operacional estratégica para o futuro — não apenas para servidores e desktops de empresa, mas eventualmente também para consumidores. A seguir estão algumas das diferenças de arquitetura e vantagens que o Windows NT tem sobre o Windows 95. (Essas comparações também se aplicam ao Windows 98.) - O Windows NT aceita sistema de multiprocessador — o Windows 95 não. - O Windows NT roda em várias arquiteturas de máquina — o Windows 95 é limitado a sistemas x86. - O Windows 95 não possui um

Máquina: Lenovo 3000 G530 (4151H8P) - SATA (AHCI):  http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20624 Este é o driver "Intel Rapid Storage Technology". Ah, não use o controlador SATA no modo IDE no Windows 7 (e no Vista). É desperdício. Confira no setup se está em AHCI antes de instalar o 7. - Vídeo: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=20601 O Windows 7 vem com driver para o vídeo integrado do chipset GL40, mas é bom colocar a versão mais nova da Intel. - Áudio: http://support.lenovo.com/pt_BR/downloads/detail.page?DocID=DS008202 Link direto: LN2AUD6WW3.exe Apesar de dizer "Vista 32bit", o arquivo tem drivers 32 e 64-bit. Estes drivers são para o Windows Vista, mas funcionam no Windows 7. Contudo, você precisa ir nas propriedades do executável LN2AUD6WW3.exe, guia "Compatibilidade", marcar "Executar este programa em modo de compatibilidade:" e selecionar "Windows Vista (Servic

Btrfs and new file system structure agreed for Fedora 17 (The H) A controversa mudança de mover as pastas /lib, /lib64, /bin e /sbin para dentro de /usr foi aprovada para ser implementada no Fedora 17. Lennart Poettering — sempre ele — fez um resumo da situação na lista de discussão fedora-devel: http://article.gmane.org/gmane.linux.redhat.fedora.devel/155792 Serão os líderes da mudança outros dois programadores da Red Hat, Harald Hoyer (dracut) e Kay Sievers (udev). Os pontos levantados por Lennart na lista, bem como os de Harald e Kay na página da especificação , me parecem lógicos: simplificar o sistema. Com uma vantagem, que será a possibilidade de ter snapshosts com o Btrfs de forma facilitada, com todos os componentes do sistema confinados numa pasta (/usr, montada no modo somente leitura). Arquivos de configuração continuam separados em /etc, dados do usuário em /home, dados voláteis em /run (um tmpfs), arquivos temporários em /tmp. Muito mais limpo. Imagine a "

O PHIRON, no FGdH, postou , faz algum tempo, que os chips gráficos SiS e VIA tinham sido descontinuados e que havia sobrado apenas o driver vesa do Xorg para usar com eles. Eu mandei uma MP dizendo que não era isso, explicando que havia sido removido o suporte 3D na libMesa (implementação do OpenGL) e que os drivers 2D do Xorg, apesar de pouco atualizados, continuavam lá. Ele felizmente editou a mensagem, esclarecendo. Na verdade, o status quo nada mudou. Mesmo antes dos desenvolvedores da libMesa decidirem matar o suporte aos chips caducos, eles não funcionavam há tempos. Era só peso morto, código morto. Ou seja, usuários de GPUs SiS e VIA estão ferrados como sempre, com um péssimo suporte. Arrisco dizer que o driver openchrome , para chips VIA, é menos pior que o sis , pois pelo menos ainda recebe algumas atualizações . O driver sis só é tocado para fazer funcionar com as novas ABIs do Xorg e mais nada. Correção dos infindáveis bugs é ficção científica. Lembrei do assunto ol