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

Até agora o CCCP não tem uma versão 64-bit. Seus desevolvedores são bem ácidos quando perguntados do porquê. Respondem que simplesmente não é necessário e ainda faltam componentes 64-bit. "Componentes", no plural, era antigamente, quando além do ffdshow e do Haali, eram usados o CoreWavPack, CoreVorbis, Gabest FLV Splitter (são os que lembro de cabeça). Com o advento do LAV Filters, a tendência é que ele substituia todos os splitters existentes (na versão 2011-11-11, aposentou o CoreWavPack e o Gabest FLV Splitter), com um código limpo, que usa as bibliotecas do FFmpeg, como comentado aqui . A decodificação fica a cargo do ffdshow, que compila para 64-bit faz tempo. O LAV Splitter existe em versão 32 e 64-bit. Olhando os componentes utilizados no CCCP 2011-11-11, a única coisa que ainda impede uma versão 64-bit é o VSFilter (DirectVobSub), que renderiza as legendas. Neste tópico do fórum do CCCP é comentado o assunto. Em resumo, o VSFilter é um código com problemas que p

Eu falei bem do Gnome 3. Hoje, não falo mais. Depois de cerca de seis meses usando-o, desisto. No começo, a novidade me despertou simpatia, vontade de me adaptar. Porém cheguei a conclusão que o ambiente me toma mais tempo do que deveria. Todo o fluxo de trabalho é atrasado por causa da falta de uma barra de tarefas. Sou mais produtivo num ambiente "normal", com uma barra de tarefas convencional. Durante todo o tempo com o Gnome 3, a minha máquina de trabalho sempre rodou o Windows 7. Ao voltar ao 7 aqui... que diferença! Tudo é mais prático, mais à mão. Os aplicativos que foram atualizados para usarem as jump lists lhe ajudam a cortar caminho e ter acesso mais rapidamente às funções principais, não o contrário, como no Gnome 3. E nos casos onde uma troca de janelas é necessária, a barra de tarefas é muito mais lógica. Sim, talvez eu esteja condicionado a um ambiente com barra de tarefas, afinal cresci usando Windows 95. Que seja. Computador tem que ser ferramenta. E a bar

Leitura introdutória: Básico sobre pacotes de codecs A última versão do CCCP (2011-11-11) traz o recente LAV Filters , que usa as bibliotecas do FFmpeg para criar filtros para o DirectShow aos moldes do ffdshow tryouts . O programa é composto por três componentes: LAV Audio, LAV Video e LAV Splitter. Os dois primeiros são filtros para decodificação de codecs de áudio e vídeo, como os nomes sugerem. Fazem o mesmo que o ffdshow. O último é o mais interessante, pois é um splitter que usa a libavformat do FFmpeg, que é capaz de demuxar vários formatos de arquivo. Por entquanto, o CCCP usa apenas o LAV Splitter. Os outros dois componentes são instalados, mas são configurados para não serem usados — o ffdshow continua sendo o responsável por decodificar os codecs. Na configuração padrão do CCCP, através do LAV Splitter, apenas AMR, FLAC, FLV, MP4 e MPEG-TS são demuxados. O Haali Media Splitter continua demuxando MKV, WebM, Ogg, mas acredito que com o tempo — quem sabe na próxima versão

Apesar de não escrever mais no FGdH, eu continuo acessando-o no modo somente leitura . E o tópico Windows 8 poderá bloquear ou dificultar a Instalação de Linux! mostra como as pessoas não se informam antes de opinarem sobre as coisas. Então vamos esclarecer: 1 - Secure Boot faz parte da especificação UEFI, que pode ser implementada por qualquer fabricante de hardware e de software, incluindo as distribuições Linux, os BSDs e tudo o mais. É um calhamaço de mais de duas mil páginas, com tudo detalhado. 2 - O mecanismo Secure Boot em si é uma boa ideia , pois permite assegurar que a inicialização do sistema operacional, em teoria, não será comprometida. Esta verificação é feita usando criptografia (opcionalmente com um TPM para verificar todo o processo) . O firmware UEFI com o recurso Secure Boot habilitado apenas carregará bootloaders assinados digitalmente cuja chave usada exista no firmware, ou seja, esteja gravada na flash ROM, no hardware da máquina. 3 - O kernel Linux no

A vantagem de escrever num blog é que eu faço as regras. Indo diretamente ao ponto: o Windows Loader, o ativador mais famoso e eficaz para Windows Vista/7/2008/2008 R2, além de servir para ativar cópias piratas do sistema, serve também para ativar cópias legais de forma simples e rápida. O uso que você dará para a ferramenta deixo a critério do seu livre-arbítrio. Introdução: como licenças OEM SLP funcionam A maioria dos PCs que vem com cópias pré-instaladas do Windows usam licenças chamadas OEM SLP. SLP significa "System Locked Preinstallation". Quer dizer que a licença está travada ao hardware. Não é o mesmo travamento que existe nas versões OEM normais. Na versão OEM SLP, o BIOS da máquina possui uma tabela SLIC na parte relativa a ACPI. Esta tabela é um pequeno código que o sistema de ativação do Windows consulta quando o esquema usado é o SLP. Para o Windows ser ativado desse modo é necessário o seguinte tripé: 1 - Tabela SLIC no BIOS. SLIC 2.0 serve para ativar

Hein, Mozilla? Faz tempo que se fala e até agora nada... Já temos os dois plugins principais (Flash e Java) compatíveis com 64-bit em versões estáveis. Versões nightly não valem. O navegador é um dos principais programas em qualquer desktop hoje e não quero brincar com software incompleto neste front. Bug report que concentra os bugs que estão bloqueando o lançamento da versão 64-bit: https://bugzilla.mozilla.org/show_bug.cgi?id=558448

Ao instalar o LibreOffice, ou qualquer outro aplicativo que automaticamente instale o Visual C++ 2008 Redistributable Package, ficarão na raiz do volume C (ou em alguma outra caso você tenha mais de uma) restos dos arquivos usados pelo instalador. Este é um bug conhecido: http://support.microsoft.com/kb/950683 Todos os arquivos listados no link podem ser excluídos com segurança depois do programa ter sido instalado. Notei o problema apenas na versão 64-bit do Windows 7 (deve ser o mesmo no Vista 64-bit). Na versão 32-bit não acontece.

Estava eu refletindo sobre o desempenho da minha máquina. A configuração dela é a seguinte: AMD Athlon II X2 260 Biostar A880G+ 2 x 2GB DDR3 1333 Kingston Value Samsung Spinpoint F3 1TB (HD103SJ) Asus Xonar DG LG GH22NS50 Seasonic S12II-430 Bronze Antec Three Hundred PC silencioso e o gabinete é bonitão e robusto. O inconveniente é que é um baita de um trambolho. A oferta de bons gabinetes pequenos no nosso mercado não é muito boa e no final acabei com o Three Hundred. Se fosse montar novamente um PC hoje, procuraria um gabinete menor. É um PC simples, com peças baratas. Estou sem paciência para reunir as notas fiscais de cada uma, mas foi uma máquina que custou uns 1000 reais, talvez um pouquinho mais (sem contar o sistema operacional). O Windows 7 Professional x64 voa baixo nela e para o uso de "escritório/internet/multimídia" é mais do suficiente. Tudo rápido, responsivo. O vídeo integrado do chipset AMD 880G (Radeon HD 4250) suporta UVD2 e o Catalyst dispon

Depois da veterana SoundBlaster Live! ter voltado da aposentadoria para me servir por mais alguns meses, novamente fiz a dança das cadeiras e voltei ao Windows na minha máquina principal. Como a Live! não tem driver para Windows 7, não teve jeito: tive que comprar uma nova placa de som. A seguir uma pequena análise da Asus Xonar DG. Quem quiser comprar uma placa de som, achará basicamente o seguinte no mercado: → Encore ENM232-6VIA (PCI, VIA VT1723 + codec VT1617A) e a sua variante 7.1 ENM232-8VIA Modelos baratinhos da Encore. Possuem drivers para Windows 7 e provavelmente funcionem a contento. Porém estava a procura de um hardware um pouco melhor. → Genius Sound Maker Value 5.1 (PCI, C-Media CMI8738) Possui driver para Windows 7, mas... ainda estava a procura de um hardware um pouco melhor. → Creative Sound Blaster Audigy SE 7.1 SB0570 (PCI, CA0106, DAC Wolfson WM8768, ADC Wolfson WM8775) → Creative Sound Blaster X-Fi Xtreme Audio SB0790 (PCI, CA0106, DAC Cirrus Logic

Havia comentado sobre o assunto no post BIOS bugados de novo . Hoje o Phoronix publicou A Proper Solution To The Linux ASPM Problem (Phoronix) nos dando a boa notícia que Matthew Garrett, o engenheiro da Red Hat que tem sido notícia ultimamente pelo seu excelente trabalho adaptando o Linux para funcionar com firmwares UEFI, descobriu uma forma de imitar o comportamento do Windows no tocante a forma como desabilita o suporte a ASPM, recurso de economia de energia do barramento PCI Express. Os testes são positivos, indicando que em todas a máquinas testadas (entre notebooks e desktops), houve diminuição significativa do consumo elétrico, voltando a níveis anteriores ao kernel 2.6.38, quando o comportamento foi alterado. Com a janela de desenvolvimento do kernel 3.2 fechada, a dúvida é se esse código virá nele ou ficará para o 3.3. Pelo menos as próximas versões das distribuições que usem o 3.2, mesmo no caso dele não vir corrigido, devem aplicar o patch por conta. Obrigado, Ma

Há algum tempo atrás, Mark Shuttleworth, o fundador e dono da Canonical, empresa por trás do Ubuntu, levantou o assunto das limitações do Xorg, que é um software que dificulta a obtenção de bons resultados, de gráficos e efeitos aprimorados. De fato, o X é resquício da década de 80 que ainda está aí incomodando. Então, com aquele ar profético, fez as "previsões" do futuro luminoso do Unity rodando sobre o Wayland, uma maravilha e tal. Este post dele foi em 4 de novembro de 2010. No Ubuntu Developer Summit 2011, que aconteceu faz poucos dias, levantou-se (novamente) a possibilidade do próximo Ubuntu, 12.04, vir com uma prévia do Wayland. O Campo de Distorção da Realidade da Canonical sempre acaba convencendo alguns incautos de que "ela está inovando", que "é uma atitude corajosa", enfim. Hoje lendo o Phoronix, pude confirmar o que eu já sabia apenas por de vez em quando dar uma passadinha no repositório git do Wayland. The Wayland Engineering Team

Algumas opções do mixer configuradas pelo ALSA não são ideais. Post feito sobre o Fedora 15 + SB0220 . Primeiramente, o PulseAudio não expõe em sua interface o controle de tonalidade que existe no hardware. Rode (como usuário normal): $ alsamixer -c 0 -c 0 é necessário, do contrário, o alsamixer mostrará o controle de volume virtual provido pelo PulseAudio. Nessa primeira imagem, para habilitar o controle de tonalidade, retire o mudo de "Tone" selecionando-o e clicando na letra M. Depois ajuste os sliders "Bass" e "Treble" de acordo com a sua preferência. Usando a seta para direita, tire o mudo de "Mic Boos" e coloque o volume de "AC97" no mínimo. A primeira serve para ativar o ganho adicional da entrada de microfone, que é importante para não ficar com nível muito baixo. A segunda, impede que você escute o que está falando no microfone, o que é obrigatório ao usar programas como o Skype para evitar ecos da sua própr

O programa de atualização de BIOS da Dell se recusará a atualizar se a bateria não estiver presente ou estiver com pouca carga. Me deparei com o problema ao tentar atualizar o BIOS do meu Inspiron 1525, cuja bateria não presta mais (não carrega mais de 5%). Felizmente existe uma opção que faz o programa ignorar a bateria. Basta chamá-lo com a opção /forceit 1525_A17.EXE /forceit [Atualização - 01/09/2012] No comentários, o Alyson confirmou que a opção funciona apenas sobre DOS. Os programas de atualização de BIOS da Dell são binários híbridos, que rodam sobre Windows e DOS. Crie um pendrive de boot seguindo o guia e faça por lá.

Ontem eu já havia lido o email de Adam Jackson na lista de discussão do Fedora a respeito, que em seguida foi noticiado no Phoronix. GNOME Shell Now Works With Software Rendering! (Phoronix) GNOME Shell will soon work without a 3D graphics driver (The H) Com drivers que não possuem suporte ao OpenGL, o mesmo será provido através do driver llvmpipe , que faz o trabalho na CPU. Não é o mesmo desempenho do suporte nativo, mas o suficiente para ter os efeitos do Gnome Shell. Desta forma, a experiência do usuário é uniformizada. Apesar de na página da especificação do Fedora dizer que o modo Fallback continuará, para os casos onde o llvmpipe também seja problemático (omelete sempre envolve quebrar ovos...), eu não vejo futuro para ele a médio prazo. O modo Fallback nunca teve o objetivo de ser "um resquício do Gnome 2 para quem não gosta do Shell". Não. É apenas um quebra-galho para hardware que não suporta o Gnome Shell. Tendo o Gnome Shell sendo capaz de rodar nes

AVISO : mexer com o MBR, bem como o uso do dd aqui comentado, é um procedimento arriscado, que pode ocasionar perda de dados. Tome cuidado e faça backup antes de prosseguir. ( fonte ) O instalador do Windows XP usa exatamente o mesmo layout, colocando o início da primeira partição no setor 63. Então, pressupondo uma instalação com uma partição apenas, o particionamento consistirá em: - MBR: primeiro setor (512 bytes) contendo 440 bytes de código booteável, 4 bytes de assinatura de disco, 2 bytes vazios, 64 bytes da tabela de partiçoes, 2 bytes de assinatura de boot (AA55h). - 62 setores vazios. - Começo da primeira partição no setor 63. O mecanismo de boot do Windows é simples, pois não envolve código variável. O código booteável do MBR procura pela partição ativa do disco. Ao achá-la, faz um chain load do VBR (Volume Boot Record) nela presente, ou seja, carrega o código booteável existente no início (primeiro setor) desta partição. Este, por sua vez, assume o comando,

Segundo a notícia AMD Catalyst 11.12 Will Be Even Better (Phoronix) sim. :-) Eu ainda não testei o Catalyst 11.10 (fglrx 8.90), que foi lançado faz poucos dias. E nem terei oportunidade, pois o Fedora 16 está prestes a sair e esta versão do driver binário da AMD ainda não tem compatibilidade com o kernel 3.1 nem com o X server 1.11, que virão no F16. Mas os (poucos) relatos do fórum Phoronix são positivos, de que o driver não está dando problema. Está deixando de ser um pudim de bugs como sempre foi. A equipe de desenvolvimento do Google Chromium recebu uma versão de teste do futuro Catalyst 11.12 (fglrx 8.92), que será lançado em dezembro, e os testes renderam a retirada dele a partir desta versão da lista negra dos drivers com suporte bugado ao OpenGL. Vamos ver se a situação no Firefox melhora também. Apesar da Mozilla ter retirado o fglrx da sua lista negra desde o Firefox 6, os relatos de problemas têm sido comuns e uma hipótese levantada foi voltar a colocá-lo na l

Esse chip de monitoramento de hardware é responsável por ativar a proteção contra escrita do chip flash ROM no qual o BIOS é armazenado. Infelizmente ele é apenas acessível via I2C e por isso o flashrom ainda não tem board enables para placas que usam-o. Eu testei numa Asus TUV4X e na lista de discussão do flashrom, da onde tirei a dica, foi testado numa Asus A7V133. Ambas usam a ponte sul VIA VT82C686B. Instale o pacote i2c-tools usando o gerenciador de pacotes da sua distribuição. Caso use o lm-sensors, descarregue temporariamente o módulo w83781d : # modprobe -r w83781d Então, carregue o módulo i2c-dev : # modprobe i2c-dev E rode o i2cset para configurar o registrador necessário para desativar a proteção contra escrita do chip flash ROM: # i2cset 0 0x48 0x80 0x80 Agora o flashrom funcionará normalmente e detectará o chip flash. Se você não fizer isso, ele não achará o chip e não será possível atualizar com ele. Não custa lembrar: atualização de BIOS é coisa

As notas de lançamento do Gnome 3.2 estão aqui: http://library.gnome.org/misc/release-notes/3.2/ Aos poucos o ambiente está sendo refinado. A mudança que de cara você nota é a nova forma como os dispositivos de armazenamento externos são tratados, agora integrados ao Gnome Shell. Anteriormente, você precisava recorrer ao Nautilus para lidar com eles. Na nova versão, ficou muito mais prático poder acessá-los através da barra de notificação.

Notícia que está por todo o lugar é que a arquitetura ARM agora é 64-bit. ARM To Move to 64bit with ARMv8 (OSNews) Jon Stokes diz diz que um dos motivadores foi a Microsoft, que teria exigido um compromisso da ARM de lançar uma versão 64-bit da arquitetura antes de prometer o port do Windows NT para ela (que sairá no Windows 8). Um racha 32/64-bit num port recém lançado não faz muito sentido mesmo. O port ARM do Windows 8, segundo ele, será lançado apenas para ARMv8 64-bit. Ele também comenta que dispositivos móveis não precisam de 64-bit por enquanto (nem num futuro próximo). Como ARMv8 segue o mesmo caminho da arquitetura x86-64 — a CPU poderá operar em dois modos, 32 ou 64-bit —, todos os mercados ficarão contentes. Quem não quiser modificar seus programas, tem o modo AArch32, que suporta o conjunto de instruções 32-bit atual da arquitetura ARMv7. Que os chips ARM com este empurrão dos 64-bit consigam expandir seus mercados. Seria muito bom poder comprar um notebook com u

No Linux existe uma variedade de sistemas de arquivos disponíveis e, consequentemente, ferramentas de verificação diferentes. A suíte util-linux possui o frontend fsck , que ao ser chamado invoca a ferramenta adequada para cada sistema de arquivos ( fsck.<sistema> ). Sem a opção genérica -a , o fsck da suíte util-linux não passa nada para a ferramenta que verificará o sistema de arquivos. E a maioria delas por padrão não corrige nada automaticamente sem a opção correta ser especificada (executam uma verificação somente leitura). A sintaxe básica é: # fsck /dev/<dispositivo> -- <opções> Não existe uma padronização definida, mas no geral a opção -a significa conserte o sistema de arquivos automaticamente sem me perguntar nada . Os dois traços são recomendados para o fsck saber exatamente que o que vem a seguir é para ele só repassar para a ferramenta, sem tentar interpretar o que significa. Man page: http://man7.org/linux/man-pages/man8/fsck.8.html No