 Jefferson,  02 de julho de 2017, hardware Quando eu me deparei com o defeito eu poderia apostar que era algo na parte “inteligente” do circuito. Para a minha surpresa era um evidente problema na fonte. Eu provavelmente não notei que a impressora não fazia o auto-teste ao ligar.
O capacitor da fonte (no centro da foto) está estufado. É normal que você não consiga distinguir isso em uma foto, mas é evidente a olho nu.

Como eu não tinha o valor original de 150uF x 200V, aproveitei o de 470uF x 200V de uma fonte ATX defeituosa. Como o capacitor é muito mais alto que o original eu preferi montá-lo deitado.


Está funcionando há semanas.
Para mais fotos internas desta impressora veja este outro post.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  02 de julho de 2017, PorDentro Eu precisei abrir essa impressora para resolver o problema que descrevo neste outro post.
Ter acesso à eletrônica é relativamente fácil. Basta remover alguns parafusos e mover algumas travas. Fica tudo em um painel do lado esquerdo.




Detalhe da fonte

Detalhe da chave de detecção de porta aberta

(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  01 de julho de 2017, manutenção Era uma operação corriqueira para mim. O HDD do cliente estava com defeito e foi comprado um novo que usei para reinstalar o Windows 10 completamente na máquina dele. Até tive o cuidado de fazer todas as atualizações para que ele não tivesse que passar por elas. Como se tratava de um computador Dell All-In-One sem uma porta sata extra eu retirei o HDD novo da máquina e o instalei juntamente com o antigo para copiar os 480GB de dados do cliente de um para o outro. Essa operação ocorreu sem maiores problemas apesar do defeito no HDD velho.
Ao reinstalar o HDD novo na máquina do cliente os problemas bizarros começaram. O primeiro foi uma nunca vista antes mensagem sobre um “RTC reset”. Fui olhar no setup mas data e hora estavam certos. O Windows 10 pareceu carregar normalmente depois disso, criei um novo usuário para o cliente e ao reiniciar a máquina fui surpreendido por múltiplos erros referentes a NTFS. Depois de umas três tentativas automáticas de reparar o Windows 10, a desagradável surpresa: tudo o que eu havia copiado para o cliente tinha sido deletado. Cada um dos diretórios e nada mais.
Como eu tinha ainda cópia dos dados isso não foi um desastre completo. Mas no dia seguinte o HDD velho do cliente já havia pifado de vez
Ainda não estou certo do que ocorreu. O Windows 10 estava hibernando quando tirei o HDD e eu não notei? Eu mandei desligar e ele hibernou? Eu não creio que tenha falado sobre isso aqui mas há quase uma década eu perdi arquivos por causa de hibernação e até tinha um aviso debaixo de meus notebooks: “saia da hibernação antes de remover esse HDD” justamente por causa disso. O Windows entra em hibernação com a memória conhecendo uma estrutura do disco e quando volta a estrutura é outra mas a memória é a mesma. Desastre certo. A mensagem sobre “RTC reset”? O BIOS dessa máquina é UEFI, que não goza do mesmo total isolamento do SO que o BIOS “legacy”. Quem sabe todas as maluquices que o SO pode provocar?
Ou foi algo relacionado com o problema que relatei em meu outro post?
Ainda é um mistério e tudo o que poso fazer é ampliar meus cuidados ao manipular arquivos de clientes e nessas operações envolvendo partições que tem o sistema operacional.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  01 de julho de 2017, manutenção Alguns minutos atrás eu me deparei pela terceira vez com esse erro no meu desktop principal. Em nenhuma das vezes eu parei para olhar o motivo porque estava ocupado com outros problemas, bastava dar um reboot para aparentemente resolver e só acontecia imediatamente após alguma mudança no hardware. Eu suspeitei que fosse alguma corrupção naquele tal arquivo de hibernação de driver que a MS cria desde o Windows 8.
Eu acredito ter descoberto a real causa quando tentava manipular o conteúdo do HDD de um cliente que eu acabara de colocar na máquina. O Windows não me deixou apagar o arquivo pagefile.sys. Como eu queria fazer uma imagem do disco e os 12GB do arquivo iam deixar a imagem desnecessariamente grande eu reiniciei pelo Windows XP apaguei o arquivo e voltei.
O arquivo pagefile.sys estava lá de novo!
Depois de considerar algumas explicações mirabolantes me deu um estalo. Fui procurar o pagefile.sys que deveria estar no meu drive C: e como eu suspeitei, não estava lá.
Aparentemente o Windows 8.1 moveu automaticamente meu arquivo de paginação para outro HDD com espaço disponível quando percebeu o espaço livre na minha unidade C: cair. O erro KERNEL_DATA_INPAGE_ERROR então deve estar ocorrendo toda vez que eu substituo o drive que está com o meu pagefile.sys com o de outra máquina.
Espero que o Windows nunca tente fazer isso com o arquivo de hibernação (hiberfil.sys). Eu só consigo pensar em coisas muito ruins acontecendo por causa disso. E assim que eu puder vou reparticionar esse HDD para dar mais espaço para a unidade C:.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  30 de junho de 2017, Drástico, mas necessário. Telefonemas com origem em outros estados são uma fonte de aporrinhação constante no fixo e no celular e em quase 100% das situações é telemarketing (também pode ser falso sequestro e outros golpes), seja descarado ou disfarçado. Não adianta dizer que você não está interessado porque aparentemente o fato de você ter ouvido a oferta é registrado como um sinal de que você pode ser persuadido. Outro dia alguém vai ligar de novo oferecendo a mesma coisa. Ou pedindo, como é o caso da LBV. Uma vez que você faça uma doação para eles, nunca mais param de ligar pedindo mais. Eu ouvi isso de uma pessoa 25 anos atrás e hoje vejo de perto eles aporrinhando a minha mãe.
Eu parei de atender até mesmo aos telefonemas da minha agência do Itaú porque 100% das vezes que me ligaram foi para oferecer serviços ou, mais desagradável ainda, alegar que eu preciso comparecer na agência para corrigir um “problema cadastral” que, eu descobri experimentando, ninguém sabe dizer qual é. Nem quem telefona, nem o “gerente” que te atende na agência. Mas é claro que ele aproveita a “oportunidade” de você estar lá para oferecer um serviço extra. Na segunda vez que alegaram isso eu deixei eles esperando uns seis meses.
Mas estou mudando de assunto.
Se aparecer no bina que o código de área não é de Recife em geral eu deixo tocando, até mesmo porque na maioria das vezes atender é perda de tempo. Você atende e a central derruba a ligação segundos depois porque não tem nenhum macaco-leitor-de-script disponível para encher seu saco. De vez em quando, se for um número desconhecido e o telefone estiver na minha frente e eu estiver bem “zen”, eu ainda atendo só para tentar descobrir qual a empresa. Seja lá para quem for a ligação eu digo que não está em casa e registro no bina a origem.
No celular é ainda mais fácil. Depois que eu aprendi a usar as listas de bloqueio do Android meus problemas acabaram. Liga, eu não atendo, verifico no Google de quem é o telefone, adiciono aos contatos e mando bloquear. Nem a campainha toca mais e no final do dia eu só vejo a lista de quantas vezes eu deixei de ser incomodado.
É claro que se eu tiver feito uma compra em outro estado é prudente que eu atenda a ligações desse estado até receber a mercadoria.
Mas se eu realmente tiver alguma relação com a empresa e for do meu interesse, A empresa certamente tem outros métodos de contato. Uma mensagem quando eu fizer login no serviço (nem consigo me lembrar de quando foi a última vez que comprei ou vendi algo sem ser por transação online) , um SMS ou email. Até mesmo uma mensagem no Whatsapp, se for uma empresa pequena.
Eu fico me perguntando se essas ligações interurbanas não são também um meio de burlar as leis estaduais anti-telemarketing. Afinal as leis obrigam as empresas a respeitarem listas de “não me perturbe” em seus estados, mas não há nada que impeça uma empresa com sede em um estado perturbar um consumidor em outro.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  29 de junho de 2017, hardware A praga do ransonware veio para ficar. Os ataques em larga escala como os que temos visto ultimamente podem parar, porque acordos internacionais podem fazer com que seja mais difícil para os bandidos obterem o dinheiro, mas ataques em pequena escala vão continuar existindo enquanto malware existir.
Daí não consigo deixar de me perguntar por que os fabricantes de HDDs não colocam uma chave que se movida desliga a gravação na unidade. Claro, isso é inútil para o drive de sistema, mas seria útil em todos os HDDs externos e em muitos HDDs internos. A chave desligaria fisicamente a gravação mas o firmware no HDD sinalizaria para o OS esse estado, evitando confusão. Cara, se isso só pudesse ser implementado em um novo release do Windows 10 eu passaria a usar essa abominação da MS só por causa disso.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  29 de junho de 2017, blog, opinião De vez em quando eu me deparo com alguém que tenta tumultuar a discussão em algum de meus blogs oferecendo como evidência de que ele está certo (e eu estou errado) um ou mais links para verdadeiras “paredes de texto” que quando examinadas cuidadosamente não suportam as afirmações feitas. Por um tempo eu achei que isso fosse pura ignorância ou preguiça, ou seja: o cara tem uma opinião diferente, faz uma pesquisa no Google, acha um link e apresenta como evidência sem nem olhar o que está escrito (talvez nem seja capaz de entender). Mas já faz algum tempo que eu parto do princípio de que seja malícia, feito propositalmente para confundir e retardar, já que eu só posso responder depois de analisar a evidência apresentada. O indivíduo acredita, com razão, que a maioria das pessoas vai se deparar com a parede de texto e se calar pelo menos por algum tempo.
E isso não acontece apenas nas discussões técnicas.
Por isso já há anos eu tenho uma política que só agora estou colocando por escrito aqui: se você não oferecer citações mostrando página e parágrafo que suportem suas declarações, eu sequer começo a ler o texto apontado como evidência e apago todas as suas declarações por suspeita de malícia. Ninguém dissemina desinformação nos meus blogs enquanto eu estiver olhando.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  28 de junho de 2017, Segurança Finalmente a telemetria da Microsoft parece servir para algo benigno.
Isso parecia ser especulação de várias empresas de segurança, mas a Microsoft confirmou que em pelo menos algumas máquinas a infecção foi iniciada pelo atualizador de um popular software de contabilidade ucraniano. Depois disso o ransonware usou várias técnicas avançadas, incluindo a vulnerabilidade Eternalblue, para se espalhar lateralmente.
A mais preocupante dessas é uma técnica que permite obter na memória as credenciais de qualquer usuário logado na máquina. Eu ainda estou tentando digerir as implicações disso.
Outra característica digna de nota é que o ransonware é um MBR infector. O primeiro que vejo em mais de uma década. O malware infecta o MBR, dá boot na máquina e finge ser o chkdsk enquanto criptografa seus arquivos na sua cara.
Ainda não ficou claro para mim se a máquina estar com Secureboot ativo seria proteção contra isso.
É claro que para fazer tudo isso dessa forma o malware precisa de permissões de administrador, que inicialmente ele obtém porque o atualizador do software de contabilidade possivelmente obtém essas permissões e mais tarde porque Eternalblue (que a essa altura não deveria ser problema) também confere essas permissões automaticamente.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  21 de junho de 2017, Segurança Lembram de quando eu falei em 2015 sobre ransonware tendo como alvo servidores Linux? Pois a empresa sul-coreana Nayana anunciou aos clientes que está processando o pagamento de um milhão de dólares (mais de 3 milhões de reais) em bitcoins para os bandidos que criptografaram os 153 servidores Linux da empresa com dados de 3400 clientes. Conforme a própria empresa cita em seu comunicado em coreano, foi o ransonware Erebus. Inicialmente os bandidos pediram 1.6 milhão mas o valor foi “negociado” depois.
Fanboys já querem justificar que isso aconteceu porque essa empresa não atualizou o Linux desde 2008. Como se isso mudasse alguma coisa. Vejam a minha posição sobre essa desculpa nos comentários do meu post de 2015.
(Prefira clicar em "Responder" se estiver comentando um comentário)
 Jefferson,  19 de junho de 2017, manutenção, Redes Na semana passada eu comecei a ter um problema com várias contas de e-mail de um cliente para o qual eu também administro o domínio. O sintoma é o Windows Live Mail não conseguir baixar o último e-mail acusando um erro após 60s. Se o usuário clicar em “aguardar” fica permanentemente assim, mas se clicar em “parar” no próximo ciclo de coleta de emails o WLM baixa todos os que tiverem chegado nesse intervalo, menos esse último.
O código de erro, cujo número não lembro agora mas vou descobrir e registrar aqui, apontava para um possível problema no antivirus. Desinstalei o mesmo em uma das máquinas mas nada mudou.
Um mesmo usuário baixando de três contas diferentes podia ter o problema em apenas uma delas. E todos os usuários que baixavam da mesma conta tinham o mesmo problema (com uma curiosa exceção) logo não parecia ser problema no WLM.
Verificando via webmail eu constatei que o email que o WLM tentava baixar não aparecia na caixa postal.
Deletar a conta no servidor de e-mail e criar de novo resolvia o problema imediatamente, mas voltava no dia seguinte.
Como esse cliente estava há uma semana usando um acesso à internet de um provedor local porque a OI estava fora do ar e o erro sugeria ser ser algo causado por “interferência” no processo, eu suspeitei do provedor, mas não tinha como testar isso. Expliquei que eles iam precisar conviver com o problema por algum tempo e ficou assim por mais dois dias até a Telemar resolver o problema da linha. Eu estava ao telefone conversando com um dos usuários sobre o problema quando o acesso foi chaveado para a OI e o problema então “sumiu”.
Os usuários somente acreditaram realmente no que eu estava dizendo quando, dias depois, a OI cortou de novo a linha deles (está uma bagunça no bairro) e o problema imediatamente voltou quando o Load Balance chaveou para o acesso de backup.
Eu ainda não sei o que o provedor faz para provocar isso, até mesmo porque ele não respondeu a mensagem que mandei para ele perguntando se ele fazia alguma idéia do que causava o problema, mas se um dia eu descobrir registrarei aqui.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
Parece que o Windows 10, por padrão, hiberna mesmo quando a gente manda desligar. Não custa dar uma olhada nisso. https://www.google.com.br/search?q=windows+10+hibernate+instead+of+shutdown&oq=windows+10+hibernate+instead+of+shutdown&aqs=chrome..69i57.35781j0j4&client=ms-android-samsung&sourceid=chrome-mobile&ie=UTF-8
Desligue o win 10 (e 8 e 8.1) segurando SHIFT