Arquivo

Archive for julho \30\UTC 2010

Intel desenvolve novo método para transmissão de dados

 

 

A Intel quer ser mais rápida. Cada vez mais rápida. Depois da Sandy Bridge, o novo chipset de processadores que ainda nem saiu de fábrica, a empresa de processadores quer ser mais veloz na transmissão de dados. A novidade é a transmissão por fótons, ou seja, por luz. É a chamada Light Peak.

A tecnologia, em fato, já vem sendo desenvolvida há um bom tempo, mas somente agora o conceito ganhou forma na mão dos engenheiros da Intel. O protótipo criado é capaz de transferir 6,25 GB por segundo – ou um filme em 720p em 1 segundo.

O funcionamento é basicamente uma conversão de luz em dados. Segundo a Intel, a velocidade alcançada pode ser até maior que a taxa atual, de 50 Gbps. A Light Peak seria uma substituta do USB 3.0 e poderia unir diversas portas de troca de dados em uma única.

A Intel promete que o conceito será desenvolvido, podendo alcançar até velocidades maiores. No entanto, a tecnologia não estará necessariamente disponível tão cedo. Abaixo, o diretor de pesquisas nessa área da Intel, Jason Ziller, exemplifica a Light Peak em um modelo maior de placa:

Fonte: info.abril.com.br

Categorias:Noticias, Variedades

Sete pessoas possuem as chaves da internet

 

Estes smart cards são mesmo as chaves da internet. Há sete deles, e eles têm o poder de reiniciar toda a world wide web "no caso de um evento catastrófico".

A ideia básica é que, caso haja um desastre na internet, o DNSSEC (segurança do sistema de nomes de domínio) poderia ser danificado ou exposto, e não teríamos uma forma de saber se uma URL aponta para o site correto. Aí entram em ação os donos das chaves:

Um mínimo de cinco dos sete donos do cartão – cada um da Grã-Bretanha, EUA, Burkina Faso, Trinidad e Tobago, Canadá, China e República Tcheca – teria que se reunir em uma base americana com suas chaves para reiniciar o sistema e conectar tudo de novo.

Pelo menos cinco pessoas são necessárias porque cada um dos smart cards contém apenas uma fração da chave de recuperação usada para consertar a internet. Ou seja, não é só uma pessoa que tem o poder de resetar nosso mundo cibernético. [BBC via PopSci]

Fonte:gizmodo.com.br

Categorias:Variedades

Multifuncional HP PSC1315: Setup não roda.

 

Este problema não está documentado no site de suporte da HP e impede a instalação de todas as impressoras das séries PSC1310 e Officejet 4200. É importante que você familiarize-se com ele, porque sua causa pode afetar outros programas.
O cliente me telefonou porque não conseguia instalar sua PSC1315 no notebook (PC1). Ele havia baixado o driver do site da HP e setup.exe simplesmente não rodava, não importando o quanto se clicasse nele. Eu lembrei-o que ele tinha o CD original de instalação e disse que tentasse com ele. Mesmo problema.
Eu mesmo já havia instalado essa mesma impressora com o mesmo CD diversas vezes nesse mesmo cliente sem problema algum (quer dizer: tirando a enorme demora habitual para se instalar os "drivers" enormes da HP). Fui até lá para tentar resolver e constatei com o Process Explorer que setup.exe até começava a rodar, mas encerrava silenciosamente um segundo depois. Nenhuma mensagem de erro.
Parti para o mais complexo Process Monitor, mas nada no (longo) log de execução me deu qualquer pista útil (ou assim pensei) do que estava ocorrendo.

Desconfiado de que fosse algo no XP SP3, testei em outro computador do cliente onde eu instalei o SP3 do zero na mesma época que no notebook e o setup rodou (PC2), então não era o SP3. Testei num terceiro PC do cliente com o SP3 e também não rodou (PC3). Depois de apanhar muito tentando entender o que poderia haver em PC1 e PC3 mas não em PC2, joguei a toalha e disse ao cliente que iria pesquisar em casa. Decidi instalar os drivers no meu PC para analisar como deveria ser uma instalação bem-sucedida vista pelo Process Monitor e para minha surpresa, setup.exe também encerrava silenciosamente no meu PC (PC4).

Eu fiquei perplexo. Tentei encontrar algo em comum entre PC1, PC3 e PC4 que não estivesse também instalado no PC2 e não estava encontrando nada. Até que me deu um estalo: quando eu coloquei o CD no PC2 apareceu automaticamente o setup e naquele momento mesmo eu pensei que não deveria ter aparecido, porque neste cliente eu desabilitara o Autorun de todas as máquinas seguindo o hack "@SYS:DoesNotExist". Mas como eu estava ocupado com um problema mais importante, não dei muita atenção. Nota: mais tarde eu cheguei à conclusão de que esquecera de desabilitar o Autourun nesta máquina específica após uma reinstalação.

E no meu PC o Autorun também está desabilitado da mesma forma. Não fazia sentido porque eu estava executando o programa diretamente, mas como era minha única pista, reativei o Autorun no meu PC (apagando a chave HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf) para ver o que acontecia.

E o maldito setup.exe rodou como deveria.
Fui examinar o autorun.inf do CD da HP e as coisas começaram a fazer sentido. A maioria esmagadora desses arquivos tem no máximo umas quatro linhas e uns poucos tem uma ou duas dúzias por usarem funcionalidade avançada (que a maioria dos usuários ignora), mas a HP decidiu fazer de Autorun.inf o "INI" do instalador. O arquivo tem 996 linhas (Edit: o da Photosmart C4200 series tem 10932 linhas) de parâmetros/diretivas e se parece com isso:

[Version]

CDGuid={18E0918E-1060-48f3-925C-56C82E88551B}

SoftwareGuid={1A5C2933-7A90-41df-97E6-2845F67834D8}

InfrastructureDatabaseList=hpomdl03.dat

LanguagesInthisCD=enu,esn,fra,ptb

DefaultLanguageInThisRelease=enu

DIVISION=hpo

ICE_REV=03

FIRST_IO_REVISION=08

LAST_IO_REVISION=08

VCD_FILEVER=09

Manufacturer=HP

RegistryManufacturer=Hewlett-Packard

ProductSeries=All-In-One Series

Pre-Install=%ProgramFiles%%Manufacturer%

SilentInstall=No

PreloadICEEngineToGUIDFolder=hpzprl01.dat

PreloadRecoveryMechanism=hpzprl02.dat

Verifiquei a versão que se baixa do site e, claro, também tinha um autorun.inf do mesmo calibre.

O problema é que o mecanismo do hack "@SYS:DoesNotExist" se baseia justamente em redirecionar toda tentativa de acesso a autorun.inf. Como setup.exe não conseguia encontrar seus parâmetros, o programa era encerrado sem explicações.

Ainda intrigado, fui checar no Process Monitor se ele não era capaz de mostrar o problema. Armado com as informações que agora eu tinha e com a ajuda da função Localizar do PM (procurei por "autorun.inf") foi fácil achar, no meio dos 1249 eventos gerados por setup.exe antes de se encerrar, evidência de que com bastante atenção teria sido possível encurtar o diagnóstico:

Perceba que cada operação bem sucedida de leitura de autorun.inf é seguida por uma ou mais falhas ao ler algo sob a chave HKLM\Software\DoesNotExist\ no Registro. É lógico que não ajuda muito quando você não sabe que conteúdo deveria ter "DoesNotExist" e você ficaria ainda mais intrigado ao perceber que "DoesNotExist" realmente "não existe" em nenhum computador. Mas nesse caso específico uma rápida busca no Google por "HKLM\Software\DoesNotExist\" traria algum esclarecimento.

É claro que estabelecer a ligação entre o erro e o bloqueio do Autorun não ajuda muito quando você sabe que ao clicar direto em setup.exe, autorun.inf não deveria ter qualquer efeito, mas pelo menos você estaria no caminho certo. Eu, pelo menos, apesar de achar sem sentido fiz o teste quando me vi sem opções e percebi (por outro caminho) a conexão. Lembre-se da famosa frase de Arthur Conan Doyle/Sherlock Holmes: "Quando você tiver descartado todo o impossível, o que sobrar, embora improvável, deve ser a verdade".

E agora você já pode ter em mente: Qualquer tentativa bem sucedida de ler um arquivo de configuração qualquer (INF, INI, etc)  seguida de tentativas fracassadas de ler uma chave no Registro pode ser culpa de algo sob a chave IniFileMapping do Registro.

Como se pode ver, o uso do hack "@SYS:DoesNotExist" tem efeitos colaterais que podem ser enlouquecedores. Por sorte, não são muitos os instaladores que "pervertem" a finalidade de autorun.inf como a HP fez e além disso surgiu recentemente outro modo eficiente de bloqueio do Autorun.

Fonte:Geringonças e gambiarras

http://jefferson-ryan.blogspot.com

Categorias:Dicas

Adobe anuncia que leitor de PDF terá modo protegido

 

A Adobe anunciou que usará sandbox como medida de segurança no seu leitor de PDF, o Reader. A técnica já é empregada no Google Chrome, e no Microsoft Office 2010.

A medida isola o aplicativo do resto do computador e evita que arquivos infectados com vírus possam fazer alterações no sistema. Assim, uma falha de segurança no programa afetaria somente o próprio aplicativo, e para acessar o sistema operacional e causar problemas mais generalizados, o ataque deveria descobrir uma falha na sandbox, também.

O recurso poderá ser desativado pelo usuário, mas virá ativado por padrão. Nem todo o programa ficará isolado desta maneira, porém: no início, serão somente comandos que “escrevem” no computador, como os que salvam arquivos. Os que “leem” coisas de fora do programa (por exemplo, ao abrir arquivos), ficarão expostos até uma segunda versão.

Como os principais riscos envolvem arquivos PDF alterados, o diretor de segurança da Adobe Brad Arkin diz que todos os recursos necessários para abrir uim arquivo PDF estarão isolados já na primeira fase. Além do sandbox, outros recursos de segurança virão, como atualizações automáticas mais frequentes e simples.

Fonte:geek.com.br

Categorias:Noticias

Em cinco anos, o Google Chrome estará na versão 36.0?

 

 

Nos fóruns e comentários dos blogs que vejo por aí, as pessoas que acompanham o desenvolvimento do navegador da Google costumam se espantar com o modo como ele “pula” de versões tão rapidamente. Além disso, causa admiração de diversos usuários o pequeno lapso temporal entre uma e outra versão estável do programa.

Para se ter uma noção, ainda não se passaram nem 2 anos do lançamento do programa e ele já está prestes a estabilizar sua versão 6.0!

Por outro lado, essa “afobação” toda não ocorre com os outros navegadores e pode estar ajudando o Google Chrome a alavancar seu número de usuários ativos, em comparação aos grandes concorrentes.

O Mozilla Firefox, por exemplo, teve sua segunda versão estável lançada após 1 ano de lançamento da primeira. A terceira versão demorou ainda mais, isto é, quase 2 anos para ser lançada. E assim por diante, seu ciclo de versões estáveis vinha durando aproximadamente 12 meses, até que a gigante das buscas entrou na guerra com seu navegador e a Mozilla teve de revisar seu planejamento.

No entanto, apesar da velocidade como são disponibilizadas essas versões, a equipe de desenvolvimento do Chromium (projeto open source do Google Chrome) divulgou hoje que aumentará a frequência de liberação de novas versões estáveis, com os principais objetivos de:

  1. Diminuir o tempo que os usuários finais levam para receber as novidades desenvolvidas;
  2. Tornar o cronograma mais previsível e fácil de ser cumprido; e
  3. Reduzir a pressão que pesa sobre os engenheiros, sempre que se tem de terminar uma nova versão estável.

O primeiro dos objetivos, se alcançado, contentará muitos usuários do navegador (quer fanáticos, quer não), pois eles passarão a receber os “grandes” novos recursos assim que estiverem completamente desenvolvidos.

Vamos dizer, por exemplo, que a Google termine o desenvolvimento da “exibição prévia de impressão”, que é um dos recursos mais solicitados pelos usuários. No entanto, digamos que os engenheiros ainda precisem, por exemplo, terminar o desenvolvimento de um novo botão, já que o cronograma dizia que a nova versão estável só seria lançada com os dois recursos prontos. O que vinha ocorrendo nesse caso era que, caso a equipe responsável não conseguisse terminar o novo botão em tempo, ou a nova versão saía sem o recurso que não estivesse pronto e ele aguardaria uns 3 meses para ser lançado, ou o lançamento de toda a versão era prorrogado. Certamente, por esses e outros motivos, a Mozilla tem tamanha dificuldade em cumprir seus cronogramas.

Podemos, também, ler nesses objetivos acima uma provável explicação para o avanço já tão rápido da numeração das versões do navegador da Google. Todavia, como divulgado, a empresa ainda não está satisfeita e pretende dobrar a velocidade do processo.

Conforme disse a Google, a partir dos próximos meses as versões serão lançadas ainda mais rápido para que os novos recursos que já estiverem prontos sejam utilizados pelos usuários tão logo se estabilizem. Consequentemente, o cronograma de lançamento será mais rigorosamente cumprido e os engenheiros poderão andar tranquilos pelos jardins do googleplex.

Os usuários (que são os mais importantes) não mais terão de esperar o longo ciclo de desenvolvimento de seu navegador, que vinha ocorrendo conforme ilustra a imagem abaixo:

google chrome ciclo desenvolvimento Em cinco anos, o Google Chrome estará na versão 36.0?

Desse modo, segundo minhas estimativas, o Google Chrome poderia chegar a sua versão 36.0 apenas nos próximos cinco anos!

Se você for realmente impaciente ou quiser experimentar os diferentes estágios de desenvolvimento do navegador, faça o download do “canal de atualização” que preferir por meio dos links a seguir: DevBetaEstável (versões para Windows).

E caso queira entender no que diferem cada um desses canais, clique aqui e leia em inglês a definição dada pela Google.

Fonte:googlediscovery.com

Categorias:Variedades

Apple lidera em número de vulnerabilidades

Empresa superou a Oracle

De acordo com um relatório divulgado recentemente pela empresa de segurança Secunia, a Apple superou a Oracle como a empresa com o maior número de falhas de segurança em seu software.
No primeiro semestre de 2010, a Apple teve mais falhas de segurança reportadas do que qualquer outra empresa.
Já a Microsoft continua na terceira posição.
A Secunia vem monitorando vulnerabilidades e boletins de segurança desde 2002, produzindo relatórios periódicos sobre o estado da segurança no mercado de software.
Juntas, as 10 principais empresas deste mercado possuem 38% de todas as falhas de segurança reportadas.

Apple lidera em número de vulnerabilidades
Apple lidera em número de vulnerabilidades

Embora isto não signifique que o software da Apple é o mais inseguro na prática, o relatório leva em consideração a severidade das falhas, ele aponta para uma tendência crescente no mundo das falhas de segurança: o papel dos softwares de terceiros.
Muitas das falhas da Apple não estão no sistema operacional Mac OS X, mas sim em softwares como o navegador Safari, o QuickTime e o iTunes.
Empresas como a Adobe, com o Flash e o Adobe Reader, e a Oracle, com o Java, também são responsáveis por grande parte das falhas de segurança reportadas.
Para ilustrar este ponto, o relatório inclui dados cumulativos sobre o número de vulnerabilidades em um PC com Windows e com os 50 programas mais usados.
Faça o download do relatório da Secunia clicando aqui (em PDF).

Fonte:Baboo

Categorias:Noticias

Apple convoca imprensa para falar sobre falha na antena do iPhone 4

 

A discussão sobre defeito no aparelho aumentou após a Consumer Reports retirar seu endosso ao produto e ações da Apple caírem.

    Na manhã da próxima sexta-feira (16/7), a Apple realizará uma coletiva de imprensa sobre o iPhone 4. Provavelmente, a companhia norte-americana usará o evento para se pronunciar publicamente sobre os problemas de interferência de sinal do aparelho.

A discussão sobre a recepção da antena aumentou, consideravelmente, após a Consumer Reports retirar seu endosso ao produto, na última segunda-feira (12/7), o que gerou uma queda no preço das ações da Apple. 

Em 2 de julho, a empresa divulgou um comunicado, culpando a falha em um algaritmo por enganar os usuários sobre sobre a intensidade do sinal e prometendo uma correção de software. No entanto, este comunicado não aborda diretamente a diminuição do sinal ao segurar o telefone, de modo a cobrir o lado inferior esquerdo.

Há alguns dias, também, a companhia recomendou que os donos de iPhone 4 comprassem um case de 30 dólares para evitar que tivessem problemas na antena.  

Além da questão da antena externa, outros usuários se queixaram de um mau funcionamento do sensor de proximidade, que encerra algumas ligações assim que o usuário aproxima o rosto do telefone.

Desde que o aparelho foi lançado, em 24 de julho, muitos relatos foram feitos sobre as falhas no sinal, o que, inclusive, levou a companhia a deletar, do próprio site, fóruns onde se discutiam o caso, alegando que “questões não técnicas” ou “discussões sobre as políticas ou procedimentos da Apple ou especulações sobre suas decisões” não são permitidas naquele espaço.

O evento começará às 10 horas, no horário local, na próxima sexta-feira (16/7), no campus da Apple, em Cupertino, Estados Unidos.

Fonte:Macworldbrasil

Categorias:Noticias