Versão beta da Steam para Linux pode ser lançada em alguns dias
Haja chaleira para tanto vapor, mas tomara mesmo que esteja prestes a condensar!
Enviado por Julian Fernandes (julianΘubuntubrsc·com):
“Que a Steam está vindo para o Linux já estamos carecas de saber, mas quando será isso? Segundo uma fonte confiável, a versão estável deve chegar em fevereiro de 2013, mas e o beta prometido por Gabe Newell ainda esse ano? Parece que chega dentro de alguns dias.
Confira os detalhes completos no post do blog Ubuntu-BR-SC!” [referência: ubuntubrsc.com]
• Publicado por Augusto Campos em
2012-09-06
@brlinuxblog
Feed RSS
E porque essa predileção especial de classificar como Vapor (fora brincar com o nome) ?
O presidente da empresa confirma, funcionários foram contratados e confirmados como trabalhando nisso, divulgação de resultados nessa área.
Outros lançamentos com menos evidências não recebem tamanha atenção de imagens vaporosas, tags e afins.
@weber jr.
Porque o Steam é a maior loja de jogos sob demanda e a noticia é a mais importante a cerca de jogos no mundo Linux desde sempre?
A predileção não é especial, mas a Steam no Linux certamente é mais vaporosa do que muitos outros produtos para as plataformas cobertas aqui. Desde novembro de 2008 a possibilidade do seu lançamento é mencionada aqui, e continua sem data, preço, detalhes técnicos, apesar de tantas figuras já terem dado o lançamento como confirmado. Mas de fato acredito que em breve ela deixará de ser vapor, ao menos neste sentido.
Shut Up And Take My Money!
“Steam no Linux certamente é mais vaporosa do que muitos outros produtos para as plataformas cobertas aqui.
Desde novembro de 2008 a possibilidade do seu lançamento é mencionada aqui, e continua sem data, preço, detalhes técnicos”
Antes desse ano sim. Mas já deixou de ser palpite de gente decifrando os binários do Steam para windows e servidores. Bem diferente do CEO vir a público confirmar e repetir.
Certo mesmo é depois que sai, mas enfim, aguardando.
Se lancar junto o dota2 pra linux, serei uma pessoa muito feliz :)
Resta saber se desta vez a coisa vai deslanchar. Esta não é a primeira vez que tentam investir no Linux em termos de games. E as vezes anteriores não são o que podemos chamar de sucesso…
Engraçado isso estar ocorrendo no momento atual, onde há muita turbulência em torno (a favor e contra) o Linux. São os dispositivos móveis tentando tomar o lugar do Desktop (a entrada da Microsoft neste mercado talvez indique que a coisa vai mudar muito nos próximos anos), são aplicativos “nas nuvens” tomando o lugar dos locais; são Icazas dizendo que o Linux no desktop morreu e são grandes empresas investindo no Linux em áreas que nunca imaginávamos que inventariam de investir novamente…. E tudo isso chegando ao auge em 2012 :-)
Tenho medo destas expectativas com o steam.O problema nunca foi isso.O problema é usar ainda linha de comando e controlar o hardware através de modo texto e outras coisas que já falei aqui .
@self_liar, eu acho uma ótima ainda podermos controlar o hardware pela linha de comando ao invés de somente por interfaces gráficas, como no windows.
O problema é não haver ferramentas visuais ou um sistema centralizado para fazer isso no Linux, como o gerenciador de dispositivos do Windows ou o ???? do Mac.
No Linux cada empresa distribui os drivers de uma maneira diferente, o que cria uma zona lascada no fim das contas. Vide NVIDIA e AMD…
Então linha modo texto como OPÇÃO tudo bem .Agora como obrigação ainda é dose.E não acredito que seja um problema de software proprietário .No windows é super fechado e o controle de hardware é controlado inteiramente por inteface gráfica.
Progrmas como o glxgears não deveriam existir.É ridiculo.
Então ,os devs de linux já deveriam pensar num gerenciador de dispositivos e um controle (basico pelo menos) de hardware por INTERFACE GRÁFICA.Ninguém quer dar modprobe nem lsmod horriveis .Tive que fazer isso no wi-fi com o UBUNTU. Isso é um absurdo.
E por favor se alguém fizer isso não faça FRONTENDS para linha de comando.Isso é uma porquice e nojeira.Não sabe programar para ter acesso direto não ?
E não venham com papo de segurança.
@self_liar, o uso de backends e frontends permite fazer em batch o que vc faz na interface gráfica, sem diferenças. É uma das coisas que faz o Linux (GNU) legal.
Já gravei 15 cópias de um CD um depois do outro, em batch usando o cdrecords. Com os mesmos parâmetros que eu usaria no k3b.
Não há nenhum problema na arquitetura de frontends.
Que absurdo de incompreensão do prompt shell e terminais é esse? Apesar de o terminal com sua linguagem shell script ser uma ponte para o coração do sistema operacional, ele é invisível para o usuário final. O sistema pode ser todo gráfico, mas não ter uma GDI como o Windows e não ter o gráfico no kernel ajuda em separação de privilégios, o que por sua vez garante maior estabilidade do sistema.
E qual é o problema com front-end? O k3b por exemplo é um frontend muito bom para diversos utilitários. De novo, o que roda em modo texto no fundo é invisível para o usuário – e o fato de termos tantos programas em texto que fazem pequenas tarefas especializadas de modo eficiente (filosofia Unix, aliás) é algo que garante funcionalidade. Em que cenário um monstrengo que agregue tudo seria melhor?
Tudo isso que você coloca como “desvantagens” do GNU/Linux, self_liar, não são desvantagens – são componentes e estratégias engenheirados (e muito bem engenheirados) para eficiência e funcionam como devem. Se você não as enxerga, é cegueira parcial sua, e recomendo que estude “The Design of the UNIX Operational System” de Maurice Bach.
Ah, e por último, ter um sistema de pacotes com dependências pulverizadas, desde que tendo um resolvedor de dependências competente (como o apt ou yum), também é vantagem, pois permite reuso de código muito mais facilmente. É mais uma coisa que o usuário final não tem que enxergar: ele escolhe o software no centro de aplicações, manda baixar e pronto. Se baixa mais algo, é coisa para um administrador de sistemas entender e manipular. Melhor do que cada programa ser um blob estático que implementa tudo dentro de seu código, e não compartilhar memória com mais nada.
Não há nenhum problema na arquitetura de frontends.
Tem problemas.Por exemplo ainda estimula a dependencia da linha de comando.Temos que entender que a linha de comando pessoal é um VESTÍGIO dos velhos tempos dos monitores verde e sem o VGA.
O software é modelado para ser uma “capa” do backend.Se entorta toda a escrita do software para se limitar aos parametros textuais e outros limites do backend.
Perda de comunicação.Isso eu vi muito com o aplicativo zip do gnome.Os backends soltavam um montão de texto.E o frontend pegava tudo aquilo numa forma imcompreensível.Sem contar que não aproveita as facilidades de cores e a capacidade 2D das interfaces gráficas.
E qual é o problema com front-end? O k3b por exemplo é um frontend muito bom para diversos utilitários. De novo, o que roda em modo texto no fundo é invisível para o usuário – e o fato de termos tantos programas em texto que fazem pequenas tarefas especializadas de modo eficiente (filosofia Unix, aliás) é algo que garante funcionalidade. Em que cenário um monstrengo que agregue tudo seria melhor?
Os utilitários unix deveriam se adequar a interface gráfica.Não se aproveita as vantagens da interface gráfica e os outros problemas acima.É melhor agregar o código fonte do backend no frontend e fazer o frontend controlar tudo.
Que absurdo de incompreensão do prompt shell e terminais é esse? Apesar de o terminal com sua linguagem shell script ser uma ponte para o coração do sistema operacional, ele é invisível para o usuário final. O sistema pode ser todo gráfico, mas não ter uma GDI como o Windows e não ter o gráfico no kernel ajuda em separação de privilégios, o que por sua vez garante maior estabilidade do sistema.
Então esta parte de segurança como falei é algo absurdo.A interface gráfica na minha opinião tem com oferecer padrões de segurança adequados.Reduzir a complexidade de um software a um tela preta e pilhas de texto para questões de segurança demonstra que o sistema não está dando prioridade a interface gráfica.Mania dos admins de servidor.
Não se pode deixar tudo isso acontecer.O mínimo do futuro são as interfaces gráficas.E olham que o pessoal já está partindo para o mundo 3D. Enquanto nós ainda ficamos com paranoia infeliz de amar cegamente uma linha de comando velha.
Ah, e por último, ter um sistema de pacotes com dependências pulverizadas, desde que tendo um resolvedor de dependências competente (como o apt ou yum), também é vantagem, pois permite reuso de código muito mais facilmente. É mais uma coisa que o usuário final não tem que enxergar: ele escolhe o software no centro de aplicações, manda baixar e pronto. Se baixa mais algo, é coisa para um administrador de sistemas entender e manipular. Melhor do que cada programa ser um blob estático que implementa tudo dentro de seu código, e não compartilhar memória com mais nada
É possivel compartilhar as bibliotecas sem usar o sistema infeliz de pacotes do jeito que está.
A parte do frontend-backend deveria ser divida em tres pedaços.Um modulo em forma de biblioteca.O aplicativo gráfico que usa deste módulo.E caso o pessoal não goste do aplicativo gráfico ,se cria um aplicativo modo texto que se comunique com este módulo.
Pronto a interface gráfica se liberta da dependencia ridicula com o modo texto.
@self_liar: o que você chama de VESTÍGIO eu chamo de HISTÓRIA. Eu acho bacana essa ideia de uma abstração entre o módulo de execução do programa (sei lá se o nome é esse…) e a interface com usuário. O que eu não concordo é ficar dizendo que quem faz diferente do que você prega é uma nojeira ou coisa assim.
Acredito que as coisas tem que evoluir sim, mas não adianta querer que as coisas aconteçam imediatamente e desconhecendo porque tomaram aquela forma. Eu pelo menos acho mais produtivo em muitos casos usar os meus 10 dedos no teclado do que ficar só empurrando o mouse e apertando botão com um dedo só.
Além disso ainda acho prematuro dizer que a interface texto deva morrer, não tenho muita certeza disto. Eu acho que cada tipo de interface tem seu uso, e nem a interface de texto nem o desktop do Linux vão morrer por que um ou outro quer isso.
Vestígio? História? Eu já disse aqui antes e repito: shell script é algo tão *futurístico* que ATÉ A MICROSOFT fez uma linguagem assim para sua plataforma, o Power Shell! Temos shells modernos – fish, zsh, até ksh93 de certa maneira – com poder e recursos equivalentes a um ambiente IDE/RAD. Não sei de onde você tirou que isso é “vestígio” ou “atrasado”, self_liar. Não poderia estar mais longe da verdade, ainda mais com a flexibilidade adicional dada por novos sub-sistemas do Linux que interagem bastante com o shell – dbus, pulseaudio e gstreamer, só pra citar alguns.
Sou só eu ou alguém mais achou que isso não faz nenhum sentido? Onde o K3b não aproveita as “facilidades de cores” (?) e a “capacidade 2D” das interfaces gráficas? Você está falando um monte de coisas sem sentido, self_liar.
A “linha de comando” não precisa aparecer para o usuário final. Ela pode (e deve, quando se requer facilidade de uso) ser invisível, pano de fundo. Mas também não deve ser removida, visto que é o ponto mais importante, flexível e competente de automatização de todos os Unix atuais.
Acho que no final a maioria não entendeu o ponto no qual o self_liar quis chegar. Pelo que entendi, ele não fala de empacotar tudo no binário do programa gráfico de modo que ele não dependa de programas de interface de comandos. Assim perderia essa modularização que é um dos trunfos do design do linux. Mas o que deveria ser feito são funções em bibliotecas compartilhadas. Ao invés do programa chamar um comando, tendo essa divisão de programas back-end e front-end, o programa gráfico chamaria as mesmas funções que o programa em linha de comandos chamaria. Assim o programa em GUI estaria executando o mesmo código que o em CLI, não o primeiro chamando o segundo.
Da forma de frontend que fazem o programa tem que criar o comando numa string e depois chamar o sistema para executá-lo e mandar o resultado. Chamar uma função diretamente no código que será compilado é muito mais elegante. No shell-script mesmo fica algo parecido, chama-se os comandos como se fossem funções. Claro que nesse exemplo mascara-se o que realmente acontece para ficar tão elegante quanto ao que acredito que o self_liar sugeriu e eu comentei aqui.
Reikainosuke Nekomata
É possível também dar comandos na interface gráfica.É possivel criar um terminal na interface gráfica caso queira mudar alguma coisa.Não se precisa ficar dependendo da tela escura irritante sem cor e sem dimensionalidade para fazer isso.
A “linha de comando” não precisa aparecer para o usuário final. Ela pode (e deve, quando se requer facilidade de uso) ser invisível, pano de fundo. Mas também não deve ser removida, visto que é o ponto mais importante, flexível e competente de automatização de todos os Unix atuais.
Isso é uma PÉSSIMA abordagem. Como eu e o usuário falou ai em cima a funcionalidade do aplicativo tem que ser separada da sua interface.A abordagem frontend-backend transforma o frontend em um emissor e receptor de comandos do backend.Assim um frontend fica muito tendencioso a se entortar para se adequar ao backend.O desenvolvedor do frontend não constroi um aplicativo legal.Sem contar a dependencia infeliz da linha de comando QUE NÃO É MAIS NECESSÁRIA.Tudo que voce falou a interface faz e melhor.
Como falei ,o ideal é separar a funcionalidade do programa num módulo e as interfaces de acesso (texto e gráfico) em dois módulos separados.Pode não parecer diferença ,mas dá sim.Mas os usuários de unix/linux insistem em fazer estas abordagens primitivas e paranoicas em manter a linha de comando.Resultado: “bah é muito mais fácil fazer tudo em linha de comando”.Mas quando dá erro a linha de comando é assustadora e sem facilidade da interface gráfica.Como falei é VESTIGIO.As interfaces gráficas podem acessar diretamente o sistema via modulos ou não.Agora depende da mentalidade dos usuários linux.SE ,mas SE quiserem sucesso terão que mudar isso com certeza.O gerenciador de hardware por exemplo do windows é um excelente exemplo de facilidade na instalação de drivers.Tudo gráfico.
Sou só eu ou alguém mais achou que isso não faz nenhum sentido? Onde o K3b não aproveita as “facilidades de cores” (?) e a “capacidade 2D” das interfaces gráficas? Você está falando um monte de coisas sem sentido, self_liar.
Um frontend com backend tem mais possibilidade de emitir mais texto do que aproveitar as capacidades 2D/profundidade e as cores da interface gráfica para expressar as ações .
Linha de comando “não tem cor” (16-256 cores isso não é cor).E errei uma parte.As interfaces texto tem um 2D limitado.Obvio pois para expressar texto tem que ter largura e altura.Mas é um 2D limitado por caracteres e não por pixels como a interface gráfica pode ser controlada todos os pixels.
Mas o que a inteface texto não tem é o aproveitamento da profundidade nas interfaces gráficas .Voce pode falar que dá até para intercalar janelas de modo texto,mas não é nada legal e cheio de limites.
Duas vantagens de usar bibliotecas em vez de frontend-backend.
Tratamento de erros muito melhor.O texto não pode desaparecer ou ter aquele coisa ruim onde o backend solta uma PILHA de erros e o frontend finge que não aconteceu nada kkkk….
Até com o K3B tive problemas.Pois o frontend não conseguia explicar o que acontecia no backend ou algumas vezes cuspia uma informação intelígivel no terminal do k3b.Não pode ser assim.
Não se limita as funções e parametros do backend.Pode se usar várias funções e parametros.
E sem essa dependencia e “repasse” de informações para a linha de comando.Que na minha opinião deve ser aposentada e deixada como opcional na melhor das hipoteses.
Cara, assim que sair eu vou jogar a minha conta da Steam direto desse beta e jogar uma boa partida de TF.
Mas eu não consigo deixar dar razão ao Augusto: Até sair mesmo, e estiver estável, fica dificil confiar. Um monte dessas promessas já foram feitas.
Afinal, o Gabe pode estar só forçando uma barra com a MS.
Como sempre, devemos fazer o seguinte: Esperar o melhor, e estar preparados para o pior.
self_liar… Não dá nem pra comentar o que você escreveu, não tem nenhum sentido, eu não saberia por onde começar. Exceto dizer que repetir à exaustão que a linha de comando é “atrasada” ou “não mais necessária” sem embasar por quê não reforça seu ponto, nem dizer que “a interface gráfica faz tudo” porque são duas abordagens diferentes (e só pra me divertir com suas tentativas, tente bolar uma interface gráfica que faça tudo o que a linha de comando do git faz, só pra dar um exemplo simples. Até hoje não conseguiram. Pensar que haveria algo equivalente em poder, rapidez e flexibilidade ao shell Unix mas em modo gráfico é – me desculpa – somente estupidez.). E o projeto de frontend e backend não é nem tão diferente do design MVC, um dos mais usados da atualidade que separa a camada de apresentação das “regras de negócios” (um nome horrível para os algoritmos do aplicativo, diga-se de passagem).
self_liar:
você está contrapondo usar bibliotecas a usar uma linha de comando e fazer o parsing disso, é isso?
Agora começa a fazer mais sentido, mas não tem nada a ver com o papo de que “linha de comando não é mais necessária” ou que shell seja anacrônico.
Aí dá pra entender melhor. Realmente, usar por exemplo a libcurl ao invés do comando curl te dá mais liberdade e flexibilidade, além de melhor tratamento de erros.
Seria melhor se por exemplo o cdrecord/wodim disponibilizasse suas funções para o k3b através de uma biblioteca? Seria. Ok. Disso não discordo, mas novamente, isso não condena a linha de comando nos casos em que ela é usável, nem a separação de backend de linha de comando e frontend que é mais útil em outros casos.
Por isso mesmo temos muitos casos em que você tem executáveis e bibliotecas ao mesmo tempo: gstreamer, curl, bzip2, apt. Um não exclui o outro, cada um tem sua adequação de uso.
Patola
É obvio que a linha de comando é atrasada.É um sistema com poucos elementos visuais.Não tem cor,não tem profundidade.Só mexe com caracteres e só.
Icones não existem na interface gráfica.Ou seja imagens e elementos gráficos não existem e alguns poucos casos dificeis de implementar.
Imagens e cores são mais eficientes que só texto e texto.
E a interface gráfica dá para ter comandos textuais.E os comandos serão até melhor tratados pois ai informação textual se agrega com o visual para se ter mais eficiencia.
Vamos dizer que o kit-grafico “modo texto teria que morrer” e que o sistema “linha de comando” teria que ser portado para interface gráfica.Assim só existiria a interface gráfica que poderia simular um terminal e manter a interatividade com todos os outros aplicativos gráficos.
Então a questão é que no unix/linux existe a porcariada de frontend-backend em algumas coisas básicas.Acho um nojo esses frotends para o apt ,apesar qu é melhor do que o texto puro.Mas usava os dois ao mesmo tempo.Pois um tinha certas coisas e o outro coisas diferentes.Super inflexível.
E comunicação com o hardware?Até esse dias tive que usar linha de comando para instalar um driver wi-fi NO UBUNTU.Cade a interface gráfica para instalar driver ? E por favor se tiver alguma que não seja um frontend porco que se comunica com as linhas de comando podres. Não tem acesso mais direto não ? Ou por bibliotecas? O unix não pode ficar nessa de fazer backend linha de comando e frontend na interface gráfico.Isso muda todo o desenvolvimento de software.
Ok, depois dessa eu desisto de continuar no thread. “linha de comando é atrasada porque contém poucos elementos visuais”… Você quer um videogame, não um computador. (E não serve doom/quake… eles têm console)
Você não fez faculdade de informática/computação, certo? Porque se fez, acho que valeria até a denúncia no MEC.
Corrigindo : icones não existem na interface modo texto.
Não estou entendendo . O que voce quer dizer?
Comandos dá para fazer TAMBÉM na interface gráfica.Esses comandos podem interagir com outros elementos da interface gráfica.Imagens e visuais são bem mais informativos do que uma pilha de texto.
TUDO que se faz no modo texto dá para fazer na interface gráfica.
Se é videogame ou não ai eu não sei.Só sei que o futuro das interfaces caminham para isso .E não é modinha de mercado.É que a interface gráfica é REALMENTE mais fácil e mais interativas oras.
Não dá para entender onde voce quer chegar.
Voce consegue fazer um polígono true color na interface modo texto? Acho que não .
Então porque essa conversa?
Podemos testar, mas sem sombra de dúvidas uma versão estável seria mais viável, como sempre podemos incorrer numa série de problemas que já é do nosso conhceimento, mesmo assim somos teimosos e não custa nada uma prévia “téstica”, eitcha que pleonasmos…!!!
Olha, self_liar, é mais ou menos o seguinte:
Interface texto é uma maneira de caracterizar, mas o mais correto seria linguagem shell. É uma linguagem de computador. Também é uma interface, um caminho pra você interagir com o computador.
Como você usa o teclado, pode escrever “palavras” que descrevem com exatidão a tarefa que quer cumprida, o que permite, uma vez que aprenda quais palavras “mágicas” são essas, fazer coisas muito poderosas, do mesmo jeito que você dizer “Descarregue os pacotes pequenos na pilha da esquerda em cima dos médios e abra os grandes para empilhar no canto direito” leva muito menos tempo e é muito mais eficiente que gesticular ou executar as instruções pra mostrar.
Mas não quero me embrenhar mais nessa discussão sobre a interface, porque o problema que percebo em ti é mais do que não perceber a importância da linha de comando. Você não percebe o *valor*, que é algo mais subjetivo. A poderosíssima linha de comando do Unix, seja bash (que eu acho um shell ruim) ou outro shell, permite a você fazer pontes e tarefas entre partes do sistema que outros sistemas operacionais não têm. Permite certas operações muito rapidamente e como está muitissimamente bem integrada ao sistema, uma vez que você a aprenda (e não é tão difícil, embora tenha seus segredos), ganha um potencial muito grande em suas mãos.
Quem cresce com isso, trabalha com isso, mexe com isso, acaba fazendo mais do que “se adaptar a uma ferramenta”. Passa a gostar de verdade, a apreciar a beleza e elegância da engenharia de algo assim. Passa a entender como faz parte do sistema Unix, chegando em alguns contextos quase a ser sinônimo de Unix.
Por isso que não vou continuar na conversa. Quem conhece a importância do shell não ligará para suas reclamações. Quem conhece o *valor* do shell provavelmente ficará um pouco ofendido com sua insistência em o tentar desvalorizar. Mas ao fim e ao cabo ninguém acatará suas opiniões, exceto quem não conhece o sistema.
E quem não conhece o sistema é quem mais provavelmente tem um trabalho tão simples que poderia ser substituído por um shell script… :P
Ah, e dizer que “elementos visuais” é o que falta no shell é de uma opinião quase infantil. Faltou pedir que eles pisquem, rodopiem e façam sonzinhos. Vamos colocar isso no java ou python que deve ficar menos chato, que tal? :P
Ah, e dizer que “elementos visuais” é o que falta no shell é de uma opinião quase infantil. Faltou pedir que eles pisquem, rodopiem e façam sonzinhos. Vamos colocar isso no java ou python que deve ficar menos chato, que tal? :P
Oras e o que que tem ?Existem projetos de “linguagens visuais”. Mas voce entendeu o que eu quis dizer ? Que não se dá para fazer imagens,poligonos como nas interfaces gráficas entende?
Como você usa o teclado, pode escrever “palavras” que descrevem com exatidão a tarefa que quer cumprida, o que permite, uma vez que aprenda quais palavras “mágicas” são essas, fazer coisas muito poderosas, do mesmo jeito que você dizer “Descarregue os pacotes pequenos na pilha da esquerda em cima dos médios e abra os grandes para empilhar no canto direito” leva muito menos tempo e é muito mais eficiente que gesticular ou executar as instruções pra mostrar.
E como falei é possível criar um sistema tipo terminal em uma interface gráfica e criar interatividade com ela.O sistema de comando por palavras obviamente tem sua utilidade.O que eu foquei é que limitar um sistema gráfico somente a isso é que é primitivo.Mas querendo ou não o caminho é a interface gráfica .É a representação visual das ações dos comandos.
Por isso que não vou continuar na conversa. Quem conhece a importância do shell não ligará para suas reclamações. Quem conhece o *valor* do shell provavelmente ficará um pouco ofendido com sua insistência em o tentar desvalorizar. Mas ao fim e ao cabo ninguém acatará suas opiniões, exceto quem não conhece o sistema.
Está apegado pela linha de comando por isso tem esta ideia errada.Mas o que temos que pensar é que a população não está apegada na linha de comando.Ela quer executar as coisas com cliques e efeitos visuais.
self_liar, você está vivendo a 2ª fase da perda (ou do luto, como é mais conhecida). Acredito que você já tenha passado pela negação. A raiva é o estágio mais difícil e tenho certeza de que o Patola o ajudará a superar.
Esquece Patola, não vale a pena discutir com o self_liar. Visite seu blog que entenderá o que estou lhe dizendo. É perda de tempo. Ignore…