Postagens

Mostrando postagens de março, 2016

Bash e cia. no Windows 10

Linux Command Line on Windows | Build 2016 (Channel 9) Ubuntu on Windows -- The Ubuntu Userspace for Windows Developers (From the Canyon Edge) Muito legal. Aí está o Subsystem for Unix-based Applications (SUA), descendente do subsistema POSIX, que o NT tem há séculos, revigorado. Chama-se agora Windows Subsystem for Linux (WSL). Ao invés de manter seus próprios binários, a Microsoft decidiu usar uma imagem com o espaço de usuário básico (Bash e demais ferramentas principais de linha de comando) do Ubuntu — menos o kernel Linux (já que o NT emula-o). São os mesmos binários de uma instalação convencional. Nada impediria usar binários de outra distribuição qualquer, acredito eu. Rede funciona e dá para instalar programas diretamente dos repositórios. Diretório raiz e $HOME ficam em %LOCALAPPDATA%\Lxss . Volumes do Windows são automaticamente montados em /mnt/<letra> . Demoliu o Ubuntu? Deve ser possível apagar a pasta rootfs dali e fazer o Windows despejar a imagem novinh

Pacotes das distribuições são realmente seguros?

Distribution packages considered insecure (Lukas's Random Thoughts) É um argumento válido e demonstrável. Não questiono a infraestrutura que gera os pacotes. Apesar de alguns tropeços no passado, as distribuições têm sistemas seguros. Trata-se dos binários entregues aos usuários, se são seguros, se não possuem falhas de segurança conhecidas. Já expressei aqui que acho a atual forma de distribuição de programas do GNU/Linux quebrada no que diz respeito aos desktops (e adiciono plataformas móveis). Porém para servidores é interessante, pois neles podemos esperar que tudo venha dos repositórios oficiais. Para o modelo funcionar, no entanto, requerimentos são necessários: empacotadores e projeto upstream responsivos. Isso nem sempre há. Como resultado, podemos ter pacotes abandonados, que ficam um tempão com vulnerabilidades e bugs diversos sem correção. Uma característica na política de atualização de versões estáveis, particularmente do Debian, mas também adotada por outras

Descent II: clássico dos anos 90

Imagem
Joguei bastante Descent II por volta de 1997, num Pentium MMX com Windows 95. Para meu deleite, achei no Mercado Livre um CD da coleção Games do Estadão: É uma cópia original do jogo, com a devida licença da Interplay. Só roda em Windows modernos dentro do DOSBox. E a resolução é limitada a 800x600 (sem cockpit) ou 640x480 (com cockpit). Felizmente o código fonte do Descent e Descent II foi tornado público para uso não comercial e não demorou para almas caridosas darem uma melhorada: DXX-Rebirth . D2X-Rebirth roda nativamente no Windows, OS X e Linux. Precisa dos arquivos com os dados do jogo da versão original (está explicado direitinho em README-D2X.txt ). Os fundadores da antiga Parallax Software conseguiram arrecadar fundos para um novo jogo, Overload [1] . Lançamento previsto para março do ano que vem, para Windows, PlayStation 4 e Xbox One. Versões para OS X e Linux são esperadas, mas talvez saiam um pouco depois. Original Descent creators jump into the

Banjo-Kazooie é excelente

Imagem
Finalmente terminei os dois principais jogos da série: Banjo-Kazooie (1998) e Banjo-Tooie (2000). As versões para Xbox 360, que estão disponíveis para Xbox One na coleção Rare Replay, possuem melhorias em comparação com as originais para Nintendo 64. Resolução widescreen, cores mais vivas e o mais importante: no Banjo-Kazooie, o jogo memoriza quais itens foram pegos. Era um bug que causava confusão no tempo do N64. A construção dos personagens, o urso Banjo e a passarinha Kazooie sendo as estrelas, é muito bem feita. Banjo é bobão, enquanto Kazooie é sarcástica. Um contraste divertido. Logo de início tomei gosto de ler os diálogos durante o desenrolar dos jogos. Valeu a pena. A mecânica de ambos é similar. Banjo-Tooie é mais longo e complexo, com muitos movimentos adicionais não presentes no primeiro jogo, e com um modo de tiro (de ovos ☺), em primeira pessoa, que, confesso, não me atraiu. A possibilidade de separar Banjo da Kazooie deu ao Tooie diversão adicional, por outro lado.

Squid 4 + systemd: combinação que funciona

Até o Squid 3.5, o comportamento do daemon é incompatível com inits modernos e exige gambiarras ou funcionalidade limitada ( -N ). Recapitulando como é até a versão 3.5: PID1 \_ MASTER/PARENT \_ WORKER <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ FILHO 1 \_ FILHO 2 ... No Squid 4, beta enquanto escrevo, é assim: PID1 \_ MASTER/PARENT <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ WORKER \_ FILHO 1 \_ FILHO 2 ... Ou seja, o processo a ser monitorado (e sinalizado) passou a ser filho direto do init, que agora pode fazê-lo via SIGCHLD. Portanto, usando Type=forking e rodando o daemon sem a opção -N , temos uma configuração funcional. Continua não bloqueando ao receber SIGTERM; o systemd, mesmo assim, aguarda o processo principal terminar, sendo finalizado corretamente. E, sem -N , o modo de múltiplos processos funciona. Desde a versão 3.5.11, o daemon não morre mais se receber SIGHUP antes de completar a

"Bloqueio de instalação de novos programas"

Imagem
Tradução: Nosso software é bugado demais para funcionar numa conta limitada. E nem é capaz de pedir elevação de privilégio para ser ao menos instalado! Portanto, destrua a segurança do seu Windows. Você estará ajudando a manter a arte da Programação Orientada a Gambiarras (POG) viva. Obrigado. (a) Circuitec