Removendo o atalho ALT + Botão direito no KDE

Usando o Blender no OpenSUSE, me deparei com o problema de usar o atalho ALT+Botão direito. Para o Blender, esse atalho significa Edge Loop. Para o KDE, significa mover a janela. Como resultado, em vez de executar a tarefa que eu queria, o atalho estava me fazendo alterar a janela. E esse é um atalho que eu nem sequer uso, então achei melhor alterá-lo.

Infelizmente, o painel de controle do OpenSUSE (Yast) não leva diretamente às opções do KDE, o que me deixou perdido por um tempo.

Procedimento: abra o menu inicial e, no campo de busca, digite "Configure Desktop" e abra o programa com ícone de ferramentas.  Agora vá em "Window Behavior" e depois abra a aba "window actions". Mude a tecla "Alt" para "Meta". Problema resolvido.

Usando MTP-tools para pegar arquivos do Android

MTP-tools é uma ferramenta de linha de comando para receber e enviar arquivos do/para dispositivos Android, conectados ao computador por um cabo USB.

Pra quê usar isso? Você querer automatizar a transferência de arquivos ou, como no meu caso, você estar com uma distro que tenha sérios problemas de usabilidade em relação a transferência de arquivos do Android.

Infelizmente, o MTP-tools é muito mal documentado. A própria manpage não é muito útil. Será registrado aqui o procedimento que eu fiz para pegar um arquivo do meu celular, depois de perceber que minha distro (Debian Wheezy com Gnome) não montava automaticamente o dispositivo.

Digamos que você queira copiar o arquivo bleu.zip, que está no seu celular, para o seu PC. Em primeiro lugar, conete o dispositivo por cabo USB e ative o modo MTP no próprio dispositivo. Em seguida, descubra o id do arquivo com:

$ mtp-filetree | grep bleu.zip

1330 bleu.zip

No exemplo dado, o id é 1330. Agora você pode baixar o arquivo com:

$ mtp-getfile 1330 bleu.zip

Pronto! O arquivo será copiado para a pasta atual.

Tradução de "Epigrams in Programming" de Alan Perlis

Segue a tradução de um texto ao mesmo tempo instrutivo e hilário: Epigrams in Programming, de Alan Perlis. Fiz uso de minha "licença poética" para converter partes do texto cuja tradução literal causaria perda de sentido. Apesar de já serem bem antigas, essas pérolas de sabedoria ainda trazem conselhos bem atuais.

1. A constante de um homem é a variável de outro.
2. Funções atrasam ligações; estruturas induzem ligações. Moral: estruture os dados posteriormente no processo de programação.
3. Açúcar sintático é cancerígeno.
4. Todo programa é parte de outro programa e raramente se encaixa.
5. Se um programa manipula uma grande quantidade de dados, ele o faz de poucas formas.
6. Simetria é um conceito que reduz complexidade (co-rotinas incluem subrotinas). Busque em toda parte.
7. É mais fácil escrever um programa incorreto do que entender um correto.
8. Uma linguagem de programação é de baixo nível quando seus programas exigem atenção a o que é irrelevante.
9. É melhor ter cem funções operando em uma estrutura de dados do que ter dez funções operando em dez estruturas de dados.
10. Entre numa rotina cedo: faça o mesmo processo do mesmo jeito. Acumule jargões. Padronize. A única diferença(!) entre Shakespeare e você era o tamanho da lista de jargões dele - não o tamanho do vocabulário dele.
11. Se você tem um procedimento com dez parâmetros, você provavelmente esqueceu um.
12. Recursão é a raiz da computação pois troca descrição por tempo.
13. Se duas pessoas escreverem exatamente o mesmo programa, e cada um for colocado em microcódigo então eles certamente não serão iguais.
14. A longo prazo todo programa se torna enfeite - e depois lixo.
15. Tudo deve ser construído de cima para baixo, exceto da primeira vez.
16. Todo programa tem (pelo menos) dois propósitos: um para o qual foi escrito e um para o qual não foi.
17. Se um ouvinte balançar a cabeça enquanto você explica o programa, acorde-o.
18. Um programa sem um laço e uma variável estruturada não vale a pena escrever.
19. Uma linguagem que não afeta sua maneira de pensar sobre programação não vale a pena aprender.
20. Onde houver modularidade haverá potencial para desentendimentos: ocultar informação implica em checar comunicação.
21. Otimização atrapalha a evolução.
22. Um bom sistema não pode ter uma linguagem de comando fraca.
23. Para entender um programa você deve se tornar a máquina e o programa.
24. Talvez, se escrevêssemos programas desde a infância, quando adultos poderíamos lê-los.
25. Só é possível mostrar informação complexa na mente. Como na visão, movimento ou fluxo ou alteração são mais importantes do que a figura estática, não importa o quão bela.
26. Sempre haverá coisas que queremos dizer em nossos programas que em todas as linguagens conhecidas só pode ser dito fracamente.
27. Assim que você entender como escrever um programa, arranje outra pessoa para escrevê-lo.
28. Com computadores é difícil achar uma medida de tempo correta para medir o progresso. Algumas catedrais levaram um século para ficar prontas. Você pode imaginar a grandeza e abrangência de um programa que levasse tanto tempo?
29. Para sistemas, o análogo de uma cirurgia plástica é adicionar ao grafo de controle uma aresta que cria um ciclo, não apenas um novo nó.
30. Em programação, tudo que fazemos é um caso especial de algo mais geral - e muitas vezes nós percebemos isso cedo demais.
31. Simplicidade não vem antes da complexidade, mas sim depois.
32. Programadores não devem ser medidos por sua genialidade e sua lógica, mas sim pela completude sua análise de casos.
33. O décimo-primeiro mandamento era "Computarás" ou "Não computarás" - eu esqueço qual.
34. A string é uma estrutura de dados crua e onde quer que ela passe há muita duplicação de processo. É o veículo perfeito para ocultar informação.
35. Todos podem aprender a esculpir. Miquelângelo teria que desaprender. É assim com os grandes programadores. 
36. O uso de um programa para provar o teorema das 4 cores não irá mudar a matemática - apenas demonstra que o teorema, um desafio de um século, provavelmente não é importante para a matemática.
37. O computador mais importante é aquele é aquele que vive em nossos crânios e busca um emulador externo satisfatório. A padronização dos computadores reais seria um desastre - e por isso provavelmente não ocorrerá.
38. Programação estruturada dá suporte à lei do meio excluído.
39. Re-gráfico: uma imagem vale 10K palavras - mas apenas as palavras que descrevem a imagem. Dificilmente um conjunto qualquer de 10K palavras poderia ser descrito adequadamente com uma imagem.
40. Há duas maneiras de escrever programas sem erros. Apenas a terceira funciona.
41. Algumas linguagens de programação são capazes de absorver a mudança, mas detém o progresso.
42. Você pode medir a perspectiva de um programador ao notar sua atitude em relação à contínua vitalidade de FORTRAN.
43. Em sistemas de software, é o pássaro apressado que faz o verme.
44. Às vezes eu acho que a única universal no campo da computação é o ciclo pegar-executar.
45. O objetivo da computação é a emulação de nossas habilidades sintéticas, não a compreensão de nossas habilidades analíticas.
46. Assim como com trocadilhos, programar é brincar com palavras.
47. Como diria Will Rogers: não existe variável grátis.
48. O melhor livro sobre programação para leigos é "Alice no País das Maravilhas"; mas é porque esse é o melhor livro sobre qualquer coisa para leigos.
49. Desistir de assembly foi nossa maçã no Jardim do Éden: linguagens que desperdiçam ciclos de máquina são pecaminosas. A máquina LISP permite aos programadores abandonar as folhas de figueira.
50. Quando entendermos os sistemas baseados em conhecimento, será como antes - só que nossos dedos estarão queimados.
51. Trazer computadores ao lar não irá mudar nem um nem outro, mas poderá revitalizar o bar da esquina.
52. Sistemas tem sub-sistemas e sub-sistemas têm sub-sistemas e assim por diante ad infinitum. É por isso que estamos sempre recomeçando.
53. Tantas boas idéias nunca mais são vistas depois de embarcar no golfo semântico.
54. Cuidado com o buraco sem fundo de Turing, onde tudo é possível, mas nada interessante é fácil.
55. Um programador de LISP sabe o valor de tudo, mas o custo de nada.
56. O software está sob constante tensão. Por ser simbólico, ele é arbitrariamente aperfeiçoável; mas também é arbitrariamente mutável.
57. É mais fácil mudar uma especificação para se adequar a um programa do que vice-versa.
58. Tolos ignoram a complexidade. Pragmáticos sofrem com ela. Alguns conseguem evitá-la. Gênios a removem.
59. Em inglês qualquer palavra pode ser verbada. Quem dera fosse assim nas nossas linguagens de programação.
60. Ao buscar o inalcançável, a simplicidade apenas atrapalha.
61. Em programação, assim como em tudo mais, errar é renascer.
62. Em computação, o invariante é efêmero.
63. Quando escrevemos programas que "aprendem", no fim nós aprendemos e eles não.
64. Normalmente são os meios que justificam os fins: os objetivos fazem avançar a técnica e a técnica sobrevive mesmo quando os objetivos desmoronam.
65. Não se engane: computadores processam números, não símbolos. Nós medimos nosso entendimento (e controle) pelo quanto podemos aritmetizar uma atividade.
66. Tornar algo variável é fácil. O truque é controlar a duração da constância.
67. Pense em toda a energia psíquica gasta tentando achar a diferença fundamental entre "algoritmo" e "programa".
68. Se acreditamos em estruturas de dados, devemos acreditar em processamento independente (ou seja, simultâneo). Por qual outro motivo iríamos agrupar itens em uma estrutura? Por que toleramos linguagens que nos dão uma coisa e não a outra?
69. A cada 5 anos, nós conseguimos uma excelente linguagem de programação. Só que não controlamos quando serão esses 5 anos.
70. Ao longo dos séculos, os índios desenvolveram a linguagem de sinais para comunicar fenômenos de interesse. Programadores de diferentes tribos (FORTRAN, LISP, ALGOL, SNOBOL, etc.) poderiam usar uma que não exija deles carregar um quadro negro em seus pôneis.
71. Documentação é como um seguro de vida: ela satisfaz porque ninguém que a faz depende dos benefícios dela.
72. Um bootstrap adequado é uma contradição de termos.
73. Não são as fraquezas de uma linguagem, mas sim as suas forças, que controlam o gradiente de sua mudança. Infelizmente, uma linguagem nunca sai de sua bolsa amniótica.
74. Seria possível que o software não seja como nada mais, que ele deve ser descartado: que o objetivo é vê-lo como uma bolha de sabão?
75. Por causa de sua vitalidade, o campo da computação sempre precisa desesperadamente de novos clichês: banalidade estraga nossos nervos.
76. É o usuário quem deveria parametrizar procedimentos, não os seus criadores.
77. A troca cibernética entre homem, computador e algoritmo é como uma dança das cadeiras: a busca frenética por equilíbrio sempre deixa um dos três em pé.
78. Se seu computador fala inglês, ele provavelmente foi feito no Japão.
79. Um ano gasto com inteligência artificial é suficiente para fazer qualquer um acreditar em Deus.
80. Contato prolongado com computador transforma matemáticos em escrivães e vice-versa.
81. Em computação, fazer do óbvio útil é a definição viva de "frustração".
82. Estamos quase lá: hoje nosso programa provou o penúltimo teorema de Fermat.
83. Qual a diferença entre a máquina de Turing e o computador moderno? É a mesma que há entre a escalada do Everest por Hillary e o estabelecimento de um hotel Hilton no seu topo.
84. Lema para um laboratório de pesquisa: naquilo em que trabalhamos hoje, outros irão pensar amanhã.
85. Apesar de que os chineses deveriam adorar APL, é em FORTRAN que eles botam seu dinheiro.
86. Nós nos enganamos se achamos que a proporção de procedimentos para dados em um sistema de banco de dados ativo pode ser arbitrariamente pequena ou mesmo pode ser mantida pequena.
87. Nós temos o mini e o micro computador. Em qual nicho semântico se encaixará o pico computador?
88. Não é culpa do computador que as equações de Maxwell não sejam adequadas para projetar o motor elétrico.
89. Não se aprende computação com uma calculadora, mas pode-se esquecer a aritmética.
90. Computação fez a árvore florescer.
91. O computador faz lembrar Lon Chaney - é a máquina de mil faces.
92. O computador é o poluidor definitivo: suas fezes são indistinguíveis da comida que ele produz.
93. Quando alguém disser "eu quero uma linguagem de programação em que eu apenas tenha que dizer o que eu quero que seja feito", dê-lhe um pirulito.
94. Interfaces mantém as coisas firmes, mas não aceleram o crescimento: funções sim.
95. Não tenha boas idéias se não pretende ser responsável por elas.
96. Computadores não introduzem ordem em lugar nenhum tanto quanto expõem oportunidades.
97. Quando um professor insistir que ciência da computação é X mas não é Y, tenha compaixão de seus estudantes.
98. Na computação, o tempo médio para a falha continua diminuindo.
99. Na simbiose homem-máquina, é o homem quem precisa se ajustar: a máquina não pode.
100. Nunca ficaremos sem coisas para programar enquanto houver programas por aí.
101. Lidar com a falha é fácil: trabalhe duro para melhorar. O sucesso também é fácil de lidar: você resolveu o problema errado. Trabalhe duro para melhorar.
102. Não se pode ir do informal ao formal por meios formais.
103. Linguagens puramente aplicativas são pouco aplicáveis.
104. A prova do valor de um sistema é a sua existência.
105. Não é possível comunicar a complexidade, apenas uma preocupação com ela.
106. É difícil extrair sentido das strings, mas elas são o único meio de comunicação com que podemos contar.
107. O debate continua: seria PL/I báctrio ou dromedário?
108. Quando dois programadores se encontram para criticar seus programas, ambos ficam calados.
109. Pense nisso! Com VLSI nós podemos agrupar 100 ENIACs em um cm².
110. Editar é uma atividade recompensadora.
111. Por que o Império Romano caiu? Como é "automação comercial" em latim?
112. Ciência da Computação é envergonhada pelo computador.
113. A única teoria construtiva conectando neurosciência e psicologia surgirá do estudo do software.
114. Em um computador a linguagem natural é não-natural.
115. Muitas pessoas acham óbvio o conceito de programar, mas impossível fazê-lo.
116. Você pensa que sabe quando você aprende, e mais quando escreve, e ainda mais quando você ensina, mas tem certeza quando programa.
117. É contra a educação moderna ensinar crianças a programar. Qual a graça de fazer planos, se disciplinar a organizar pensamentos, dedicar atenção a detalhes e aprender auto-crítica?
118. Se você consegue imaginar uma sociedade em que o computador-robô é o único trabalhador, você consegue imaginar qualquer coisa.
119. Programar é anti-natural.
120. Adaptar velhos programar para novas máquinas normalmente significa adaptar máquinas novas para se comportarem como velhas.

Enviando emails com VBscript ou PHP a partir do IIS

Este post é para aqueles que usam IIS como webserver e precisam mandar emails a partir de uma página em VBScript (ASP clássico) ou PHP (CGI ou FastCGI) . Também é requisito usar um servidor SMTP remoto, porque eu não vou ensinar a configurar o Windows como servidor de email.

O segredo é usar os objetos COM da família CDO. A documentação online desses objetos é escassa, incompleta e incoerente, mas há bastantes exemplos de código para copiar-e-colar. O exemplo abaixo mostra como enviar um email usando VBScript e um servidor SMTP localizado em smtp.imeiu.net.

'criando o objeto
Set myMail=CreateObject("CDO.Message")
'assunto
myMail.Subject="Exemplo de mensagem"
'remetente
myMail.From="fulanodetal@servidor.com"
'destinatario
myMail.To="beltrano@outroservidor.com"
'corpo da mensagem
myMail.TextBody="Exemplo de corpo de mensagem"
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/sendusing")=2
'Servidor SMTP remoto
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver")="smtp.imeiu.net"
'Porta do servidor remoto
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserverport")=25
myMail.Configuration.Fields.Update
myMail.Send
set myMail=nothing

A seguir temos um exemplo análogo em PHP. A função mail() não funciona no IIS, a não ser que o servidor local seja configurado como servidor de email.

//criando o objeto
$myMail=new COM("CDO.Message");
//assunto
$myMail->Subject="Exemplo de mensagem";
//remetente
$myMail->From="fulanodetal@servidor.com";
//destinatario
$myMail->To="beltrano@outroservidor.com";
//corpo da mensagem
$myMail->HTMLBody="Exemplo de corpo de mensagem";
//sempre use 2
$myMail->Configuration->Fields["http://schemas.microsoft.com/cdo/configuration/sendusing"] = 2;
//Servidor SMTP
$myMail->Configuration->Fields["http://schemas.microsoft.com/cdo/configuration/smtpserver"] = "smtp.imeiu.net";
//porta do servidor
$myMail->Configuration->Fields["http://schemas.microsoft.com/cdo/configuration/smtpserverport"] = 25;
//atualiza e manda
$myMail->Configuration->Fields->Update();
$myMail->Send();

Naturalmente, este artifício só pode funcionar no Windows, pois o Linux não tem objetos COM.

Enviando emails do linux com Postfix

Este breve tutorial irá ensinar como enviar emails a partir de uma máquina Linux. Você poderia usar o Thunderbird ou algum outro aplicativo de interface gráfica facilmente configurável para ver seus emails, mas o objetivo aqui é poder enviar mensagens a partir da linha de comando e de bash scripts.

Iremos configurar e usar o Postfix em um sistema Debian. Parte-se do princípio de que o leitor está em seu computador pessoal, com um IP dinâmico e sem um domínio público. Isso significa que será preciso ter uma conta em um servidor de emails que aceite conexões SMTP. No exemplo, nós nos conectaremos ao Yahoo, mas todos os outros grandes servidores de email servirão. Usuários do GMail precisam saber que devem ativar a opção de "liberar acesso a aplicativos menos seguros" para que as instruções aqui funcionem.

Como estaremos trabalhando com SMTP, será possível apenas enviar emails. Pegar mensagens do servidor de email exige um procedimento totalmente diferente.

Preparações

 

Instale o Postfix com:

#apt-get install postfix

Isso irá desinstalar o Exim, que já vem por padrão com o Debian.

Agora descubra como se conectar ao seu servidor de email. No caso do Yahoo, as instruções, no momento desta postagem, dizem para se conectar a smtp.mail.yahoo.com, porta 465 ou 587. No entanto, o Postfix aceita apenas a porta 587.

Será preciso editar e criar arquivos na pasta /etc/postfix/, além de ler arquivos em /var/log/. É preciso ser root (ou usar sudo) para fazer essas coisas.

Vamos nos basear num caso fictício em que o usuário "batman" manda emails do computador "caverna", com domínio "localdomain", que é o domínio inválido padrão. No servidor do Yahoo, o email de login é "bruce_wayne@yahoo.com.br", com senha "euamogotham".

Arquivo de configuração

Abra o arquivo /etc/postfix/main.cf. Ele contém as principais configurações do postfix. Ele já virá com um bocado de configurações padrão no seguinte formato:

• Cada linha segue o padrão "constante = valor";
• Linhas começando com "#" são ignoradas;
• Linhas começando com espaços em branco são continuação da linha anterior.

O seu arquivo deve definir pelo menos as seguintes constantes:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_generic_maps = hash:/etc/postfix/generic
smtp_tls_security_level = may
relayhost = [smtp.mail.yahoo.com]:587
myhostname = caverna.localdomain

A primeira linha diz que usaremos autenticação.
A segunda diz o arquivo onde estarão as credenciais.
A terceira diz que não nos comunicaremos anonimamente, ou seja, mandaremos as credenciais ainda que o servidor não peça.
A quarta linha determina um arquivo com informações para reescrever o endereço de remetente.
A quinta linha diz que usaremos SSL/TLS, protocolos exigidos em qualquer servidor de email decente.
A sexta diz qual será nosso servidor relay de SMTP.
A última diz quem somos. Essa informação não é muito útil, já que é um domínio falso que não pode ser acessado publicamente, mas é necessária para a reescrita do remetente.

Credenciais

 

Crie o arquivo /etc/postfix/sasl_passwd. Ele guardará as credenciais em uma única linha, conforme mostrado a seguir:

[smtp.mail.yahoo.com]:587 bruce_wayne@yahoo.com.br:euamogotham

 A linha tem o servidor, com a porta, um espaço e depois o login e a senha separados por dois-pontos. O Postfix não irá ler esse arquivo mas sim um outro, gerado a partir desse, com extensão ".db". Tendo escrito o arquivo, vá para a pasta /etc/postfix/ e execute o seguinte comando:

#postmap sasl_passwd

O comando anterior gera o arquivo sasl_passwd.db. Você pode até mesmo apagar o arquivo de texto sasl_passwd se quiser, mas saiba que se você precisar alterar as credenciais, será preciso gerar o arquivo ".db" novamente.

Reescrita de remetente

 

Se você tentar mandar o email agora, ele irá com o remetente "batman@caverna.localdomain". Alguns servidores de email reescrevem automaticamente o remetente (como o do Hotmail/Live/Outlook), mas outros (como o do Yahoo) não irão aceitar a mensagem, porque o domínio do remetente é inválido. A solução é reescrever o remetente, que é um processo parecido com o das credenciais.  Crie o arquivo /etc/postfix/generic, com a linha única mostrada a seguir:

batman@caverna.localdomain    bruce_wayne@yahoo.com.br

Depois entre na pasta /etc/postfix/ e use o comando a seguir para criar o arquivo .db:

#postmap generic

Na teoria isso deveria ser suficiente para reescrever o remetente, mas na prática pode ser uma boa fonte de dor-de-cabeça, porque o Postfix tem outros mecanismos para alterar os endereços, e eles podem entrar em conflito. É preciso realizar muitos testes para assegurar que as transformações estejam acontecendo como desejado.

Finalização e teste

 

Execute o comando a seguir para reiniciar o Postfix:

#postfix reload

Você pode usar um programa de email como o Mutt para testar o envio de emails. Você pode enviar para interface de usuário dele ou com um comando como esse:

$ echo mensagem | mutt -s 'assunto' coringa@arkham.com

Definindo fones de ouvido como saída de som padrão no Linux

Eu não uso caixas de som, ligo os fones de ouvido diretamente na saída de som padrão traseira da placa-mãe. Sabe-se lá por quê, mas o Xubuntu não detecta os fones como saída padrão de áudio e o som fica mudo até que eu mude manualmente a saída de som. Sempre que eu reiniciava o computador, tinha que alterar manualmente a saída de padrão de novo.
Descobri como alterar de forma permanente essa configuração e vou registrar aqui, mas antes vou ensinar como alterar de forma manual e temporária, caso o leitor não saiba.

Alterando visualmente de forma manual e temporária

Procure por um programa chamado "PulseAudio Volume Control". Ele vem por padrão no Xubuntu, mas pode exigir instalação manual em outros DEs/distros. Vá em Outut Devices, depois procure por Builtin Analog Audio Stereo e altere o valor de port para headphones. Esses termos podem estar traduzidos para português em sua distro. Na minha máquina, e não sei por quê, está escrito "unplugged" logo ao lado de headphones na seleção de port, mesmo que os fones esteja claramente plugados. Essa configuração irá se desfazer no próximo desligamento da máquina, mas pelo menos não exige conhecimentos de terminal.

Alteração permanente

Em primeiro lugar, abra um terminal e execute:

ps ax | grep pulseaudio

O objetivo é ver como o pulseaudio foi iniciado. Se você não vir algo como

/usr/bin/pulseaudio --start --log-target=syslog

então talvez essa dica não funcione com você. Agora execute o comando pacmd. Esse programa recebe comandos de configuração que alteram o funcionamento do pulseaudio. Quando o prompt novo surgir, digite list-sinks. Você verá um monte de coisas, mas o importante é encontrar o número da sink e o nome do port que você quer. No meu caso, o número da sink era 1 e o nome do port era "analog-output-headphones". Quando terminar, saia do pacmd com um CTRL+d.

É preciso agora alterar o arquivo /etc/pulse/default.pa e definir nele a saída de som padrão. Saia que os comandos que o default.pa interpreta são os mesmos que o pacmd, então você pode testar nesse último antes de escrever no arquivo. No meu caso, acrescentei as seguintes linhas:

set-default-sink 1
set-sink-port 1 analog-output-headphones

A primeira linha define a sink padrão (saída de som interna) e a segunda define o port padrão (fones de ouvido).

Problemas no boot do Windows depois de resetar a BIOS

Eu uso dual-boot de Linux e Windows e recentemente tive um problema em minha placa de vídeo que me forçou a resetar a BIOS. Especificamente, a placa parou de funcionar completamente e eu tive que trocar a saída de vídeo padrão, que era a PCI-Express, para a Onboard. Não podia fazer isso pelo menu de configuração da BIOS justamente por não poder ver nada, então tive que resetar a BIOS à força.

Após o reset, o GRUB funcionou e o Linux continuou bootando normalmente, mas o Windows 7 travava sempre que entrava na animação das bolinhas coloridas, fazendo o computador reiniciar. O boot seguinte perguntava se eu queria reparar a inicialização. Supus que esse procedimento iria sobrescrever a MBR e me fazer perder o GRUB, então não aceitei.

A solução, por estranho que pareça, é trocar o modo de operação do HD SATA de IDE para AHCI no menu da BIOS. Aparentemente o Linux tolera os dois modos de operação, mas o Windows 7 não.