Caixa Seca

Ghost Solution Suite (GSS) é uma suíte fantástica de clonagem e restauração de imagens de sistemas operacionais. É um software robusto, fácil de usar, que nunca falhou comigo. Velho e confiável Ghost de guerra Pensei que havia sido abandonado; parou faz tempo na versão 2.5.1 (11.5.1.2266), que suporta apenas até o Windows 7/2008 R2. UEFI não é suportada. Ainda serve para quem tem parques usando BIOS ou UEFI+CSM com o Windows 7 em MBR. Apesar da combinação estar ultrapassada, deu para ir contornando pois o Windows 8 fracassou. Contudo, daqui a pouco, quando o Windows 10 der as caras e o pessoal começar a migrar, o problema vai aumentar. Fico feliz de saber que estão trabalhando na versão 3.0! ( beta no momento) When will come new Version of Ghost - GSS 3.0? (Symantec Connect) What's New in Ghost Solution Suite 3.0 (PDF, 936 KiB)

Este foi o ápice da ruindade. Ninguém aguentava mais. Os usuários domésticos estavam ávidos (mesmo sem saber) por um puro-sangue NT. O indefectível Windows ME

Windows 10 Technical Preview compilação 10049 (x64) rodando o Microsoft Office 2000 Small Business. Considerando a data de lançamento do SR-1, são quinze anos de compatibilidade binária!

O pessoal da Canonical adicionou na versão 219-git um novo daemon ao systemd, o systemd-fsckd . Na futura 220, será removido . Implementa um recurso que o Ubuntu tem (desde sempre?) de exibir durante o boot gráfico (Plymouth) o progresso da verificação dos sistemas de arquivos, além de oferecer ali opção para o usuário cancelar o processo. Está sendo removido por alguns motivos: - O systemd-fsck (sem o "d" no final), que roda o fsck genérico (que, por sua vez, roda o fsck de cada sistema, ufa!) e existe há muito tempo no projeto — sem integração com o Plymouth —, já é considerado um hack. Sistemas de arquivos que requerem fsck preen são tecnologia do passado. Btrfs não precisa, XFS nunca precisou. Falando no XFS, agora que o formato V5 está pronto , seu futuro é ser o máximo possível self-healing . - Oferecer opção para cancelar o fsck é arriscado. É dar aos usuários a arma engatilhada para o tiro no pé. - As verificações completas disparadas por intervalo de

Windows Vista. Até que eu gostava dele . Só não me agradava a constante atividade de disco. Desativando a restauração do sistema (que desativava também as cópias de sombra se não me engano) melhorava. O Superfetch era outro que influenciava, ainda não havia sido ajustado como no Windows 7 e superiores. Fora isso, nada a reclamar. Um sistema muitíssimo melhor do que o XP. O cuidado era usar pelo menos o SP1 (hoje o SP2 é obrigatório para receber atualizações do Windows Update) e ter hardware suficiente. A versão RTM tinha bugs horríveis. Não era tão ruim assim não...

O Squid pode operar em dois modos no que diz respeito à forma do daemon: com a opção -N ou sem ela. Com -N , não é feito o processo de daemonização. É o preferido em inits modernos. Deve ser usado sempre que possível com o Upstart ou systemd. Contudo, o modo de múltiplos processos do Squid não funciona com -N até agora (3.5) e as distribuições, portanto, não podem usar por padrão. Sem -N , ativa a daemonização. No systemd, isso significa um serviço Type=forking . À primeira vista, não haveria problema, pois existe compatibilidade. Não fosse o comportamento totalmente bugado do Squid ao funcionar dessa maneira. PID1 \_ MASTER/PARENT \_ WORKER <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ FILHO 1 \_ FILHO 2 ... Os problemas insolúveis são dois: - O processo que deve ser sinalizado (worker) não é filho direto do init. Isso impede o systemd monitorá-lo eficazmente via SIGCHLD. Ele lhe avisa com "squid.service: Supervising process XXX wh