A notícia estourou esta semana, a Apple vai deixar de usar os processadores Intel nos seus processadores, em favor de chips projetados internamente, baseados em arquitetura ARM. Não é totalmente uma surpresa, uma vez que ela já projeta os chips dos seus celulares e tablets, que estes chips são plenamente capazes de assumir mais carga de trabalho, que a Apple vem sabidamente enfrentando problemas com os chips Intel em termos de aquecimento, com o consequente throtling, e por fim, que os rumores sobre isso já circulam faz tempo. Então não é propriamente motivo de surpresa. Assim como não seria se a Microsoft decidisse fazer o mesmo na linha Surface, pois existem não apenas rumores sobre isso faz tempo, mas tentativas concretas, como no Windows RT. Mas agora que a Apple realmenet anunciou oficialmente, e que é um fato concreto, isto dá oportunidade para uma série de considerações interessantes.
sábado, 27 de junho de 2020
domingo, 14 de junho de 2020
O modo (correto) de resolver os conflitos de relógio no dual boot Ubuntu/Windows
São problermas recorrentes que eu enfrento quando configuro um PC para dual boot, e como acontecem com intervalos muito grandes, um dois anos, acabo esquecendo... Um é decorrente do UEFI secure boot, que já documentei aqui no blog, e o outro, mais trivial mas também chato, é o do relógio.
O usuário logo vai perceber, depois instalar o dual boot e de alguns boots nos dois sistemas, que o relógio está errado. Logo vai imaginar a causa: os dois sistemas interpretam o relogio "da BIOS" (o termo tecnicamente mais correto é o RTC da placa mãe, real time clock, mas coloquei assim para facilitar a referência). O Windows interpreta o valor que está no RTC como o horário local, já considerando o fuso horário. Para o Brasil é o time zone -3. Já o Ubuntu (testei recentemente no 20.04 LTS) interpreta por default como o horário UTC, a time zone 0, e depois faz a conta para mostar na tela. Por default também os sistemas atualizam automaticamente o relógio, e por isso ele vai mudando de um para o outro.
Nesse ponto minha primeira reação foi desabilitar a atualização automática. Mas basta pensar um pouco para notar que não vai adiantar, não existe um valor fixo que atenda aos dois sistemas. Mesmo que você se conformasse em ficar vendo horário errado, existem outros problemas nisso (sem spoilers, vou explicar a seguir).
Aí me veio a idéia de "fraudar" a time zone no Linux, dizendo que eu estava na time zone 0 (por exemplo, Reikjavik, na Islândia), e o horário local no RTC ficaria o do Rio de Janeiro. Aparentemente funcionou, ambos passaram a mostrar exatamente o horário do RTC, e por alguns dias me senti o "espertão". Mas esta solução tem um problema grave, que só identifiquei depois.
Depois de alguns dias comecei a receber um erro da atualização do Ubuntu, e depois de mexer na configuração das atualizações, que o sistemas estava "up to date" por vários dias seguidos. Estranho. Mexi de novo nas atualizações e o erro voltou. O problema aqui foi relacionar relógio com atualizações. Tentei "apt-get update" no terminal, e veio uma mensagem mais específica. Pesquisando esse erro na Web, em 10 minutos vi que a causa era o relógio (e sem esse recurso de pesquisa, sabe-se lá quanto tempo levaria, me assusta como ficamos dependentes da Web).
A raiz do problema é que o sistema e o servidor de atualizações precisam confirmar os horários. E o horário do RTC estava errado, ou seja, no mundo real em Reykjavik não é o mesmo horário que no Rio. E como vimos o Ubuntu considera o RTC como sendo o valor do UTC, e não o que é mostrado na tela. Ou seja, mexendo abritráriamente nos relógios e time zones não há como compatibilizar os dois sistemas para mostrar os valores corretos de relógio e ao mesmo tempo manter as atualizações (e esse foi só o primeiro efeito colateral).
Mas existe uma solução mais limpa. É possivel alterar como o Ubuntu lê o RTC, para que passe a considerar como o horário local. Na mesma pesquisa Web citada antes veio a solução:
timedatectl set-local-rtc 1
A solução foi encontrada neste tópico. Depois de testar vários boot e a atualizações, o problema parece resolvido. E vim aqui no blog para registrar, quem sabe da próxima vez que eu configure um dual boot eu lembre pelo menos de ler aqui...
Nota: eu citei no título e no artigo o Ubuntu e não o Linux em geral, poorque não sei neste momento como as outras distribuições estão se comportando quanto ao relógio. Mas caso tenha um problema parecido em outra distro, este pode ser o caminho.
O usuário logo vai perceber, depois instalar o dual boot e de alguns boots nos dois sistemas, que o relógio está errado. Logo vai imaginar a causa: os dois sistemas interpretam o relogio "da BIOS" (o termo tecnicamente mais correto é o RTC da placa mãe, real time clock, mas coloquei assim para facilitar a referência). O Windows interpreta o valor que está no RTC como o horário local, já considerando o fuso horário. Para o Brasil é o time zone -3. Já o Ubuntu (testei recentemente no 20.04 LTS) interpreta por default como o horário UTC, a time zone 0, e depois faz a conta para mostar na tela. Por default também os sistemas atualizam automaticamente o relógio, e por isso ele vai mudando de um para o outro.
Nesse ponto minha primeira reação foi desabilitar a atualização automática. Mas basta pensar um pouco para notar que não vai adiantar, não existe um valor fixo que atenda aos dois sistemas. Mesmo que você se conformasse em ficar vendo horário errado, existem outros problemas nisso (sem spoilers, vou explicar a seguir).
Aí me veio a idéia de "fraudar" a time zone no Linux, dizendo que eu estava na time zone 0 (por exemplo, Reikjavik, na Islândia), e o horário local no RTC ficaria o do Rio de Janeiro. Aparentemente funcionou, ambos passaram a mostrar exatamente o horário do RTC, e por alguns dias me senti o "espertão". Mas esta solução tem um problema grave, que só identifiquei depois.
Depois de alguns dias comecei a receber um erro da atualização do Ubuntu, e depois de mexer na configuração das atualizações, que o sistemas estava "up to date" por vários dias seguidos. Estranho. Mexi de novo nas atualizações e o erro voltou. O problema aqui foi relacionar relógio com atualizações. Tentei "apt-get update" no terminal, e veio uma mensagem mais específica. Pesquisando esse erro na Web, em 10 minutos vi que a causa era o relógio (e sem esse recurso de pesquisa, sabe-se lá quanto tempo levaria, me assusta como ficamos dependentes da Web).
A raiz do problema é que o sistema e o servidor de atualizações precisam confirmar os horários. E o horário do RTC estava errado, ou seja, no mundo real em Reykjavik não é o mesmo horário que no Rio. E como vimos o Ubuntu considera o RTC como sendo o valor do UTC, e não o que é mostrado na tela. Ou seja, mexendo abritráriamente nos relógios e time zones não há como compatibilizar os dois sistemas para mostrar os valores corretos de relógio e ao mesmo tempo manter as atualizações (e esse foi só o primeiro efeito colateral).
Mas existe uma solução mais limpa. É possivel alterar como o Ubuntu lê o RTC, para que passe a considerar como o horário local. Na mesma pesquisa Web citada antes veio a solução:
timedatectl set-local-rtc 1
A solução foi encontrada neste tópico. Depois de testar vários boot e a atualizações, o problema parece resolvido. E vim aqui no blog para registrar, quem sabe da próxima vez que eu configure um dual boot eu lembre pelo menos de ler aqui...
Nota: eu citei no título e no artigo o Ubuntu e não o Linux em geral, poorque não sei neste momento como as outras distribuições estão se comportando quanto ao relógio. Mas caso tenha um problema parecido em outra distro, este pode ser o caminho.
Assinar:
Postagens
(
Atom
)