Postagem em destaque

WSL: Backup e Restauração

Imagem
Às vezes você tem um drive mais rápido (SSD) que o outro (HD). É o meu caso: meu drive C, é um SSD de 256 GB e meu drive D, é um HD de 512 GB. Um é pequeno e rápido; outro é grande e lento.  Meu drive C, por ser pequeno, acabou ficando sem espaço. Então fui pesquisar por grandes arquivos (usei o excelente TreeSize Free para isso) e descobri um tal de ext4.vhdx que tinha 29 GB. Esse arquivo é a imagem do disco do WSL no Windows e é normal ficar grande. O problema é que mesmo você apagando arquivos ele não diminui. E quando você usa o Docker, a situação se agrava rapidamente. Então, descobri uma maneira de compactar esse arquivo/disco. É um comentário da KarolineWss numa issue do WSL. Funciona maravilhosamente bem. Tanto que consegui diminuir praticamente pela metade o arquivo.  Mas para fazer isso, claro, pesquisei como fazer backup (e restauração). Esse artigo é sobre isso. E com um bônus, esse o arquivo fica numa localização meio complicada para humanos, mas fazendo um backup e uma

Artigo 6 - Bug do ano 2000

(Publicado originalmente entre 1994/95)

Bug pode ser traduzido como problema, erro, defeito. Só que o do final deste milênio será provavelmente o maior de todos os tempos. O problema todo começou por falta de planejamento ou visão. Pois as datas, dentro dos programas, eram armazenadas no seguinte formato: dd/mm/aa. Ou seja, dois dígitos para o dia (correto), dois dígitos para o mês (correto) e dois dígitos para o ano (econômico). Econômico porque a até alguns atrás o espaço para armazenamento (tanto em memória quanto no disco rígido era extremamente caro). A data no formato dd/mm/aa precisa de 25% menos espaço do que no formato dd/mm/aaaa. Um registro que tenha 10 datas no formato dd/mm/aa, precisará de mais 20 dígitos para ficar no formato dd/mm/aaaa. Se existirem 100 mil registros, o arquivo irá crescer 2 milhões de dígitos.

Por exemplo, quando num sistema (programa), que armazene as datas no formato dd/mm/aa, entramos com a data de 15 de Janeiro de 2000, o sistema irá guardá-la como 15/01/00. Se fôssemos tirar um relatório com data maior que 31/12/98 o sistema não mostraria essa data de 15/01/00, porque (para o computador) 15/01/00 é menor que 31/12/98.

Existem soluções como a que um engenheiro de Joinville apresentou, que consistia em utilizar os meses de 13 a 24 para representar os anos de 2000 a 2099, 25 a 36 para os anos de 2100 a 2199, e assim até os meses de 85 a 96 para os anos de 2600 a 2699.

Para se corrigir um sistema de tamanho médio, como um Sistema Comercial Integrado (contas a pagar e a receber, estoque, faturamento e banco), de cerca de 100 mil linhas de programa, a um custo por linha de código de US$ 0,70, gasta-se US$ 70.000,00. Pelo menos alguém saiu ganhando nesta situação: os programadores. Que já estão, em alguns casos, até negando serviço. Além disso, o preço por linha de código a ser verificado está subindo sem parar. Estima-se que até o ano 2000 o preço por linha de código chegue a US$ 7,00, dez vezes o preço atual.

E não é só no ano 2000 que os programas começarão a acusar o problema. Desde já, os programas precisam estar preparados, pois num financiamento de 5 anos (60 meses), as datas que forem lançadas deveriam estar no formato dd/mm/aaaa, caso contrário, essa pessoa passaria a ter um dívida de 100 anos!

Comentários

Postagens mais visitadas deste blog

Netflix não mostra ícone de streaming

Google Hacking

FTP não funciona no PHP