Caixa Seca

Tempos atrás o MasT3R postou sua configuração para reprodução de vídeos no Windows. Leitura obrigatória . Postarei a minha. É mais simples, pois uso apenas o MPC-HC e o LAV Filters. Compilações nightly do MPC-HC: http://xhmikosr.1f0.de/mpc-hc/ (pode usar sem medo, raramente estão bugadas) LAV Filters: http://forum.doom9.org/showthread.php?t=156191 Versão 64-bit do MPC-HC aqui. LAV instalado com as opções padrão (inclui os filtros 32 e 64-bit). Das configurações do MPC-HC que não são preferências pessoais, duas: Em "Filtros Internos", nos campos "Filtros Fonte" e "Filtros de Transformação", clique com o botão direito em qualquer parte e selecione "Desabilitar todos os filtros". Esse trabalho será feito pelo LAV Filters. Em "Legendas", desmarque "Elevar à potência de dois". Segundo o MasT3R, apenas cacarecos precisam disso. LAV Video Configuration: Se sua GPU suportar decodificação de MPEG-2, H.264, p

SC-AK330LB-S, SC-AKX50LB-K Logo de cara, a diferença notável entre os dois é o primeiro pesar bem mais. Boa chance de ser devido ao transformador da fonte linear e a maquinaria para os decks de fitas cassete. O segundo é um projeto mais novo, que usa fonte chaveada. Lembre: aparelho de consumo. Ambos tocam MP3. O SC-AK330 é limitado pois você depende de CDs para escutar os arquivos, enquanto o SC-AKX50 possui uma porta USB, além da memória interna de 2 GiB, e a capacidade de "gravar" em MP3, tanto para a memória interna quanto USB, áudio proveniente do CD e do rádio. Ele também permite copiar arquivos da porta USB para a memória interna. Lê FAT e FAT32. No SC-AK330, o trabalho de decodificação de MP3 é feito pelo IC7002, o processador responsável pela unidade do CD. No SC-AKX50, é mais interessante. A parte responsável pela (de)codificação de MP3 está no "RIPPING AUDIO LSI" (IC801) presente na "placa Jupiter". Este processador comunica-se com I

Em era de smartphones, estou aqui na resistência. Antes do 2600, nem lembro os modelos que tive... Nokia 2600 Pé-de-boi. Caiu no chão umas quinhentas vezes e nunca refugou serviço. Nokia 5310 XpressMusic Quando comprei-o lá por volta de 2008 o que mais pesou na escolha foi a saída de fone de ouvido com pulgue de 3,5 mm para substituir meu MP3 Player (haha) SanDisk Sansa C100, que havia morrido. Na época, saída de 3,5 mm não era comum como é hoje. Um celular estiloso, pequeno e leve. A câmera, contudo, era muito ruim e extremamente lenta para processar e salvar as imagens. Nokia C3 No começo do ano passado, a bateria do 5310 já tinha ido para o espaço. Os Asha recém tinham sido lançados. Preferi o C3, um pouco mais antigo. Teclado QWERTY. Qualidade de som muito boa. Câmera bem melhor que a do 5310. Não é uma qualidade de imagem para substituir uma câmera digital, mas dá para quebrar o galho para fotografias "rápidas". A gravação de vídeo é fraquinha (320x240, 15fps

Plaquinha de captura de TV analógica, A/V, S-Video, FM. Encore ENLTV-FM3 SAA7134HL, TEA5767, SA9801 PCI\VEN_1131&DEV_7134&SUBSYS_21081A7F&REV_01 Site da Encore .

Sem LVM/RAID por software, um initramfs não tem muito propósito. Podemos pulá-lo e dizer para o kernel montar diretamente o sistema de arquivos de uma partição e executar /sbin/init . Daí para frente, o systemd assume o comando. Para isso, alguns requerimentos: - O kernel precisa ter o suporte ao controlador de disco e ao sistema de arquivos usado na partição compilados como bulit-in , ou seja, não podem ser módulos. - O sistema de arquivos raiz não pode ter o diretório /usr separado. - O bootloader não deve carregar o initramfs. Infelizmente o kernel do Arch não tem o primeiro item nem pretende ter. No Fedora, sim; contudo, apenas o driver ext4 (que serve para EXT2/3 também) e os drivers ahci e ata_piix são built-in . Para pular o initramfs, remova a linha "initrd" do bootloader e passe para o kernel as opções: root=/dev/sdxy rootfstype=xyz O sistema de arquivos precisa ser especificado (usar o mesmo nome do módulo), pois, lembre, o kernel está sozinho. Nã

Aviso de utilidade pública! O rootkit "G-Buster Browser Defense", ou GbPlugin para os íntimos, da Caixa Econômica Federal, Banco do Brasil e outos brancos é fonte conhecida de lentidão. Como qualquer outro software, também recebe atualizações. Senti alguma melhora depois de atualizá-los em algumas máquinas. Falha minha não ter anotado as versões que estavam em uso. Atualizados diretamente via: http://www.caixa.gov.br/completo https://www14.bancobrasil.com.br/plugin/instala.exe Instalado o da Caixa primeiro. Pede para reiniciar (afinal é instalado além de um serviço, um driver de dispositivo no kernel). Depois, instalado o do BB. Desta vez, não pediu para reiniciar -- acho que ele aproveita o serviço/driver instalado pelo da Caixa. Relacionado: Adeus ao GbPlugin

Depois de um longo período sem compilações novas, Sherpya voltou: http://oss.netfarm.it/mplayer-win32.php

Para você que reclama do Tracker do Gnome, espere para saber que o KDE 4 requer o MySQL ( não é de hoje... ). Isso mesmo, um SGBD desse porte num desktop. Por padrão. Não existem palavras para expressar o que penso. Imagine aí alguns palavrões. No Arch, o pacote que traz a dependência é o Akonadi. Prováveis cadeias: - mysql, requerido por akonadi, este requerido por kdepimlibs, que por sua vez é requerido por kdebase-runtime, do qual o ambiente inteiro depende. - kdebase-runtime tem a dependência em kdepimlibs como "optional". Caso o seja de fato, outra possível cadeia é kdepimlibs ser requerido por libkgapi e libkolab, que são requeridos por kdepim-runtime, do qual kdebase-workspace depende. Dizendo para o Pacman ignorar qualquer pacote da cadeia aborta a instalação com "dependências não resolvidas". Segundo este post do fórum do Arch, o openSUSE quebra o Akonadi em pacotes runtime/lib [1] , sendo que o runtime (que depende do MySQL) só é necessário caso

Final sysvinit deprecation warning Hoje, alguns pacotes do Arch ainda distribuem os scripts SysV (pasta /etc/rc.d ) simultaneamente com os arquivos unit do systemd (pasta /usr/lib/systemd/system ). Como o Pacman não ativa nada por padrão -- e, no caso de um script ter o mesmo nome do arquivo .service, o último tem preferência --, não causava quebradeira. Confuso, contudo. Agora, o time do Arch tomou a decisão final para limpar a situação: nos pacotes que ainda possuem scripts SysV, os mesmos serão removidos em futuras atualizações. Para encerrar a conta, os pacotes initscripts e sysvinit serão removidos do repositório. \o/ Boa viagem!