Google Chrome com suporte ao Unity
Via André Gondim:
A última versão lançada do navegador do Google, o Google Chrome 12 adicionou um suporte ao Unity, para integrá-lo ao Unity, assim com o LivreOffice. Veja como ativá-lo no link a seguir. (via andregondim.eti.br)
• Publicado por Augusto Campos em
2011-06-15
@brlinuxblog
Feed RSS
“LivreOffice”.
2
“LivreOffice” ????
3
“LivreOffice”??
Liverdade!!!!
Comenter a notícia que é bom nada né?
Bando de pirralho!
Já ativei aqui.
herrar é umano
Aqui deu certo tambem. ;-)
Excelente, os dois funcionaram, valeu pela dica!
Alguém sabe se já corrigiram aquele ‘bug’ que impedia plugins equivalentes ao NoScript de rodar no Chrome (e consequentemente bloquear javascripts até do google) ? Eu posso tocar de browser, mas sem uma proteção do mesmo nível do NoScript, nada feito.
@Mauro, isso não é um bug e sim um feature. Se o Google colocar esse tipo de recurso no Chrome uma extensão defeituosa pode causar efeitos colaterais como lentidão, travamento ou outro tipo de comportamento bugado.
Enfim, é improvável que o Chrome tenha isso nos próximos anos.
Uma coisa confusa no Chrome, é que a ordem dos botões fechar e maximizar variam se a janela estiver maximizada ou restaurada.
@jrk
“@Mauro, isso não é um bug e sim um feature. Se o Google colocar esse tipo de recurso no Chrome uma extensão defeituosa pode causar efeitos colaterais como lentidão, travamento ou outro tipo de comportamento bugado.
Enfim, é improvável que o Chrome tenha isso nos próximos anos.”
Isso é piada, né?
@ Mauro, Kashmir
http://forums.informaction.com/viewtopic.php?f=10&t=1676&sid=1645f14670fc562a90bc3b3f8174eb97&start=60#p26081
Talvez esta postagem e a próxima na sequência elucidem a questão. A verdade é que a forma como o Chrom(e|ium) trabalha é que torna o uso do NoScript impossível.
@kashmir não, estabilidade e velocidade são levados muito a sério pelo Google.
E depois no próprio Chrome é possível definir os sites que podem executar JS. Quem exige os recursos avançados do NoScript que utilize o Firefox (que é o que eu faço).
@Bremm
Bom, entendi o problema. Entre velocidade e segurança optaram por velocidade.
Mas acho muito estranho considerar isso um feature por não expor efeitos colaterais como lentidão, travamento ou outro tipo de comportamento bugado de uma extensão defeituosa, como o jrk falou.
@Bremm:
Obrigado pela informação. Uma pena que com isso nunca vou usar o Chrome nem o Chromium. Com já havia exposto, sem um equivalente do NoScript, nada feito para mim.
Pelo que entendi, o Chromium cria sandboxes, uma para cada página, de forma que um processo/página não possa interferir em outro(s). Até aí tudo bem. A parte engraçada disso é que com o Flash da Adobe (em 64 bits) acontecia uma coisa peculiar: no momento em que, digamos, havia uma falha em um página do Youtube, as demais páginas abertas com animações em Flash ou vídeos em FLV também acabavam falhando também. Tentei inclusive misturando FLVs de diversos lugares, um em cada aba, e o resultado era o mesmo. Dava crash em uma aba e em seguida as demais caíam como pecinhas de dominó. =(
http://www.google.com/support/forum/p/Chrome/thread?tid=0d782f19a7a1a9ec&hl=en
As postagens acima são recentes, mas o problema é antigo. E não é só no pinguim, no janelas acontece o mesmo…
Obs.: não testei com o Gnash.
@Bremm sandbox serve para executar a página com privilégios diferentes do app e a divisão em processos serve para melhorar a estabilidade. Até aí tudo bem, o IE já fazia tudo isso antes do Chrome sequer ser anunciado.
Já um plugin não pode ser colocado em sandbox pois necessita de privilégios como acesso ao sistema de arquivos. Como os navegadores (exceto o Opera?) criam um processo apenas para o plugin, quando ele trava todas as páginas usando o plugin são afetadas.
Entendo que o Ubuntu passa por mudanças sensíveis ao trocar o gerenciador de janelas e, mais recentemente, sinalizar a troca de navegadores. Lança um desafio à sua própria base de usuários – ou estaria mesmo interessados em uma nova geração de usuários? Não seria difícil dobrar 1% de usuários, se podemos acreditar nas estatísticas. Talvez, quando o Linux deixar de ter 1%, não será mais Linux…
@Jrk
Era essa explicação que eu queria “desencravar” para perguntar a razão pela qual o NoScript não poderia funcionar. Não sei se dá para comprar uma sandbox do Chromium com uma regra do AppArmor, mas no segundo é possível dizer o que o programa pode ou não pode acessar e deixar ele “esperneando” caso precise de algo que não tenha sido liberado. E ainda há o modo “complain” para ver quais recursos o programa acessa, antes de criar a política de acesso do mesmo com o aa-genprof (há quem prefira o aa-autodep para “adivinhar” o que o programa irá usar, mas não uso).
Como sou um cara “baixo nível”, pois não entendo muito da parte de GUI, DM, navegadores etc. e acabo por fazer essas comparações aparentemente malucas, mas no fundo possuem a mesma lógica.
O Chromium era um cujo perfil que criei deixava ele praticamente “enjaulado” nos diretórios de configuração, cache. desktop e downloads, barrando o acesso dele a quase todo o resto (deixava livres apenas acesso aos plugins, fontes e bibliotecas necessárias).
Grato pela explicação (caso haja uma próxima, grato também antecipadamente).
s/comprar/comparar
@Bremm
Em about:flags tem uma opção que parece resolver esse problema do processo único do Flash:
“Executar PPAPI Flash no processo do renderizador
Se a versão PPAPI do Flash estiver em uso, execute-a em cada processo do renderizador em vez de executá-la em um processo de plug-in dedicado.”
Nesse link tem uma pequena explicação sobre o PPAPI:
http://chromestory.com/2011/04/run-ppapi-flash-in-the-renderer-process-new-in-chromium-flags/
@Bremm O fato de um NoScript não funcionar não tem nada a ver com sandbox ou processos. Apenas o Google acha que não o custo/benefício de implementar APIs que o NoScript necessitaria não vale a pena.
@Lagarto
Vou testar aqui numa instalação que uso via pendrive. Ela serve para quando chego em uma loja e quero ver se o PC funciona bem com uma instalação padrão do Ubuntu. Obrigado!
@jrk
Outra hipótese levantada foi a do NoScript “sabotar” as propagandas do Google — mas não sei até que ponto é possível considerar isso, pois é possível barrar muita coisa usando o Stylish (menos JS, é claro). Apesar de que resolvi o problema aqui (não só do Google mas de todo tipo de “ad”) usando um conjunto de regras no DNS redirecionando toda url de site com ads invasivos para 127.0.0.1 sem choro nem vela. A lista-base copiei daqui: http://pgl.yoyo.org/adservers/
As propagandas do BR-Linux são comportadas, então nunca mexi nelas. Mas em outros lugares a quantidade de banners, flashes e demais parafernálias é demasiada.
A parte chata dos ads do Google é que eles geralmente deixam pouco espaço em sites com CSS mal formatados.