Sobre “popularidade” e “Market Share, tenho meus dois centavos de contribuição.

Inicialmente, este texto, está na Linux vs Windows no Orkut, em resposta a um tópico sobre insegurança no Linux. Escrevo aqui, com pequenas modificações ao texto original!

A nível de divulgação, recomendo a leitura destas duas matérias para um maior esclarecimento:

¹ http://www.guiadopc.com.br/noticias/12291/o-preco-da-popularidade.html

² http://www.keepgeek.com.br/2009/12/08/desenvolvedor-cria-malwares-para-gnulinux/

Segue:

Market Share

Em minha humilde opinião, a parcela de mercado, só pode ser calculada por números totais vendidos por determinada empresa em determinado segmento, e comparado-o diretamente a soma total das vendas de seus concorrentes, tirando-se assim essa porcentagem ou parcela de participação mercadológica.

Como posso calcular e comparar um produto concorrente, que pode, é, e deve ser adquirido gratuitamente em sua maior forma de aquisição e distribuição em uma área onde vendas praticamente não existem?

Se não existem vendas do sistema, logo, não podemos considerar participação de mercado! Posso estar equivocado, mas a lógica é esta.

Talvez, como disse a um tempo, é mais fácil tentar calcular a ‘Base Instalada’, onde tais, se tornam potenciais clientes com o passar da carruajem, onde as empresas que trabalham com o mercado de Linux, podem oferecer e vender produtos com base em Suporte técnico, aplicações específicas, hardware homologado … entre outros.

Popularidade

Aqui acredito que a ‘teoria’ base instalada, possa se encaixar melhor neste ponto: “popularidade”.

Mudando um pouco o assunto, a quantidade de Linux instalada, seguindo a ideia do Market Share, representamos somente a 1% do pedaço da pizza, (segundo a NetApplications) com a soma de todos os sistemas operacionais juntos. Você acredita nisso?

O ponto que percebo, trata-se no dizer, que a base instalada, não condiz exatamente com a pratica de Market Share.

Se o Linux é popular, é perceptível então, que sua base instalada, é muito maior do que muitos pensam…

Se é popular, é por que é usado! Com isso, cai por terra em dizer que “somos a turma do 1%”, … infelizmente para uns, felizmente para outros.

Market Share = Giro de Capital
Base instalada != Market Share

Agora sobre o tópico em questão….

O sentido de ser popular, é significado de ser o mais desejado, das pessoas quererem tê-lo… onde entra o desejo “consumista”, e neste caso, não existe a necessidade real de se ter capital de giro para que o desejo se torne realidade. Estamos falando de Software Livre e Código Aberto, que pode ser adquirido com custos irrisórios, mínimos ou ao custo de um download. Também é bom lembrar, que nem por isto, significa que todo o Software Livre e de Código Aberto não deva ser cobrado, mas isto é outra história e vamos nos centrar em outros pontos.

Concordo que tendo uma fatia maior do bolo, seja em popularidade ou seja em market share, o sistema irá se tornar mais visado.

O preço…

Com muito mais gente querendo, usando… algumas mentes, vão descobrir ou inventar uma forma de se burlar a segurança deste sistema.

Quando um método funcional está pronto, e claro, com a permissão e ajuda de um usuário (vamos chamar assim…) desatento, basta apenas jogar a rede e esperar os peixes chegarem.

Sim… existem muitas coisas que dependem da interação com o usuário para que funcione!

O que neste caso, diferencia o Linux de muitos outros sistemas, mesmo tendo binários que podem ser executados em qualquer distribuição Linux em sua maioria, este possui níveis de implementações diferentes entre um distribuidor e outro, e em muitos casos, modificações feitas pelos próprios usuários, sendo este mais técnico e/ou mais avançado tendem a causar diferenças significativas de um modelo padrão de sistema em comparação direta ao “mesmo” software rodando em máquina de outros usuários.

Os níveis, variam desde o tipo de login que é permitido no sistema, á até o tipo de gerenciador do ambiente desktop que será utilizado. Além é claro, dos tipos de softwares que estão rodando sob o capô.

No exemplo do ocorrido, o que temos?

• Ubuntu
• Gnome
• sudo
• instalação de um programa ou tema que necessita da interação com o usuário
• usuários desatentos

Percebem que para redirecionar ou mesmo “montar” um software espião, um vírus ou um cavalo de tróia que deverá funcionar, necessita  de uma certa “combinação de fatores” para que seja bem sucedida?

Isto, por si só, já não atinge o total dos “1%” dos desktops (segundo o Market Share!). Mesmo!

Eu por exemplo, uso KDE, ArchLinux, noexec no /home, e não uso sudo.. e o grande detalhe é que não sou desatento …  Em meu caso, é muito difícil de eu ser infectado por uma “praga”, ou melhor dizendo.. script como este.

Agora imagine o desperdício de tempo e esforço, montar um malware que seja compatível ao menos com todas as variantes de Ubuntu?

Agora imagine o esforço exponencial para que se crie um malware que funcione ao menos nas 5 distribuições mais populares existente hoje?

Para o “cracker”, é óbvio que seria inviável…

O pensamento correto seria algo como: - É muito mais fácil atacar apenas um tipo específico de usuário e determinada distribuição linux, como dependência, um determinado software rodando, que tentar algo que não terá sucesso ao generalizar todas as distribuições em um único pacote.

E isto ocorre, graças a desatenção do usuário! É isto. Um ataque especifico, tem muito mais chance de ser bem sucedido, que um ataque globalizando a maioria da diversidade Linux.

Creio eu, que isto explica muito, o porque do Windows ser o “mais” atacado! Ele é único em todos os seus pontos, não importando onde está instalado.

Não escrevo isto dizendo que o Windows é mais ou menos eficiente em sua segurança ou por ter mais Market Share ou Base Instalada, mas, digo isto, com o intuito de mostrar que por padrão, todo Windows é igual, assim como uma distribuição específica, voltada ao usuário final acaba sendo igual em sua base de usuários.

Vide OpenSuse, Mandriva, Ubuntu… temos diferenças gritantes entre Mandriva e Ubuntu. Aproximando ainda o software da Canonical, Kubuntu e Ubuntu possuem diferenças claras e que de certa forma inviabiliza algo que englobe as duas vertentes (uma com KDE e outra com Gnome).

Mesmo, no caso do OpenSuse, um  com Gnome e outro com KDE, o padrão instalado mesmo sendo igualitário (é a distribuição OpenSuse), possuí vertente de software e uso diferentes.

Já um mesmo tipo de pescaria ou ataque como este em um sistema Debian, Slackware, ArchLinux ou Gentoo, seria muito mais difícil de ser bem sucedido, pois, são os usuários que escolhem desde a base do sistema a até os detalhes mais ínfimos de seus ambiente de desktops que deverá ser utilizado, passando por infinitas variedades de softwares e formas de segurança, evitando assim, algo do tipo.

Agora o que também me chama a atenção, é que um portal como o Gnome-look,(poderia ser o KDE-Look, ou qualquer outro portal) com o tamanho e ‘popularidade’ destes, permitem que pacotes de temas e softwares infeccionados, acabem caindo nas mãos de usuários finais, sem uma analise técnica mais profunda ou sem nenhuma por parte deles!?

É um esforço e tanto, mas pelas doações, usuários mais experientes e mesmo entre os administradores, poderiam formar uma equipe de análise sobre temas e software lá disponíveis antes da liberação ao público em geral!

E finalizo aqui meus dois centavos de contribuição a este assunto!

Preload: Como acelerar o tempo de carregamento de aplicativos no Linux

Se você não anda satisfeito com o tempo de resposta de abertura de alguns aplicativos que você mais utiliza no GNU/Linux, você, com certeza precisa conhecer o Preload.

Então, deixe-me apresentá-lo….

Preload é uma aplicação para linux, que roda em segundo plano fazendo registros estatísticos sobre o uso dos programas mais frequentes do cotidiano. Conforme for colhido os dados destes programas, suas bibliotecas e binários, serão pré-carregados em memória no Linux, e com isto, os aplicativos  são iniciados com menores tempos e maiores velocidades, alcançando resultados mais rápidos e satisfatórios para nós.

Seu processo monitora as aplicações que os usuários executam, analisa estes dados, prevê que os usuários possam executar tais aplicativos, e carregam os binários e suas dependências na memória para que com isso, possa diminuir os tempos de inicialização.

Para instalá-lo no ArchLinux, basta um #pacman -S preload

Uma vez instalado, ele iniciará o processo de pré-carregamento, e nenhuma ação adicional é necessária.

Para aprendermos sobre as opções de configuração, controlar as atividades, e personalizar nossas próprias configurações e indicar o que o Preload trará de melhoria para o sistema, podemos editar o arquivo preload.conf que está no /etc.

Configuração

O arquivo de configuração do preload é mantido em /etc/preload.conf, trazendo valores padrões que devem ser ideal para a maioria dos usuários. Mas se você quer ajustar a forma como o preload irá operar, uma breve explicação das opções disponíveis no arquivo de configuração é de grande valia.

Algumas opções mais usadas são:

Opção	Padrão	Controles
Configuração do modelo de Cache (sistema)
model.cycle	20 [segundos]	Tempo em que o Preload irá repetir uma consulta no sistema para atualizá-lo sobre o modelo de programas e bibliotecas de cache.
model.halflife	168 [horas]	Em quantas horas o Preload irá começar a “esquecer” sobre os dados registrados. A relevância estatística do atual modelo perde 50% de sua importância.
model.minsize	2000000 [bytes]	O montante mínimo de chamadas feitas no sistema, para que um aplicativos que seja considerado pelo Preload. Um número menor significa um cache do Preload para aplicações menores, enquanto que para fazer cache de Preload apenas para aplicações com maiores tamanho, basta aumentar esse número.
Configurações de Memória
A Formula usada para determinar o máximo de memória disponível para o Preload é: (Total RAM x model.memtotal) + (RAM disponíveis após a inicialização x model.memfree) + (Memoria em Cache x model.memcached)
model.memtotal	-10%
model.memfree	100%
model.memcached	30%

Como já observado, os valores padrões devem ser suficientes para a maioria das pessoas, e você realmente não deve alterar esses valores, ao menos que tenham uma finalidade específica em mente.

Existe uma certa preocupação sobre o uso de memória pelo Preload, e é bom ressaltar e  deixar claro que ele não irá drenar memória do seu sistema! No artigo original, o autor escreve que  em seu sistema com 1GB de RAM, o Preload alocou 83670kb… como tamanho máximo de memória disponível, usou 35% do que estava livre naquele momento!

Monitoramento

Se você quiser saber sobre os recursos que o Preload está usando, você pode acompanhar o seu arquivo de log, usando tail-f /var/log/preload.log como super-usuário.Por padrão - você pode definir manualmente a verbosidade do Preload com a “flag” -V , para obter mais informações, consulte a página do Preload no Manual [man] – , isso não lhes traz muita informação sobre o preload, exceto a quantidade de memória alocada e quantos arquivos  estarão sendo monitorados. Caso precise de mais informações sobre os arquivos específicos que o cache do Preload observa, verifique o arquivo /var/ lib/preload/preload.state

Uma coisa bonita sobre o preload, é que você pode ignorar completamente esses arquivos (como se eles não existissem), independente disso, você pode querer verificar o registro de vez em quando, só para se certificar de que está rodando, mas felizmente o preload irá ficar quietinho no canto dele sem lhes incomodar.

Números

Vai demorar um pouco antes do preload começar a entender seus padrões de uso, por isso não espere ver uma mudança drástica no desempenho de imediato. Além disso, se você apenas abrir e fechar aplicações repetidamente, o computador irá armazenar os arquivos em cache de qualquer maneira (isto é chamado warm” load, ou no bom português, carregamento “morno”), assim você não verá nenhuma diferença na velocidade. No entanto, veremos uma melhoria da velocidade se, por exemplo, usar um programa de forma intermitente, estes programas serão iniciado mais rápida do que sem o preload.

Exemplos? Firefox, OpenOffice, Games que mais utiliza….

O autor do preload, Behdad Esfahbod, escreveu um artigo no qual ele apresenta alguns números de exemplo e resultados mostrando um pequeno benchmark com o uso do preload:

Aplicação	Inicialização sem o Preload	Inicialização com o Preloaded	% de ganho
Login no Desktop	30s	23s	23%
OpenOffice.org Writer	15s	7s	53%
Firefox	11s	5s	55%
Evolution	9s	4s	55%
Gedit Text Editor	6s	4s	33%
Gnome Terminal	4s	3s	25%

Tenha em mente que estes números não representam medições em hardware atual e foram gerados já a algum tempo.

As máquinas modernas provavelmente vão bater com folga o tempo bruto desses números, mesmo em tempos de inicialização sem o preload, mas obviamente ainda veremos uma melhoria na velocidade com ele.

O Preload estando configurado para ser carregado durante a inicialização, é perceptível a melhora com a quantidade de tempo que se leva para acessar um desktop completo.

Conclusão

O Preload pode proporcionar uma grande melhora no tempo de inicialização de aplicativos, desde que as máquinas mais modernas tenham uma boa quantidade de memória livre; o preload colocará esta memória RAM para ser utilizada de uma forma que o sistema não sobrecarregue.

É altamente recomendável instalar em sua máquina de trabalho, e embora possa demorar um pouco para o daemon conhecer os seus hábitos antes de vermos qualquer melhora de desempenho real, é uma grande ferramenta que irá aumentar gradativamente  a velocidade de carregamento de seu sistema.

Fontes e artigo original:

Techthrob.com

SourceForge/Preload

http://behdad.org/download/preload.pdf

Desabafo… Firefox precisa emagrecer!

Até parece contradição se comparado ao post anterior, mais não é!

Estava com o Firefox 3.5.2 aberto 4 abas e o consumo da memória exponencialmente exorbitante => 238,5 Mb.

- Firefox = papão de memória

Então, desativei todas as extensões e plugins no Firefox e olha só que beleza:

Dos 238,5Mb consumidos, as mesmas 4 páginas abertas em abas, passou a consumir um total de 190,2 Mb.

Não tem idéia.. Firefox com ou sem extensões continua um beberrão, um comilão, um porco papão de memória.

4 abinhas abertas e esta consumindo este absurdo! ¬¬”

Ele (o Firefox) com Mplayer Plugin (Plugins de DivX, Google VLC, QuickTime, Real Player, Windows Media Player), Shockwave Flash, Silverlight, Skype, Java….  Extensões: Adblock Plus, Adblock Plus Filter Uploader, Greasemonkey, Hide Menubar, Novell Moonlight, Twitterfox…

Com todas estes plugins e extensões, um total de 238,5 Mb.

Isto significa que todas estas extensões e plugins pesão 48,3Mb
O problema não está nas extensões nem nos plugins, então: – Como pode 4 abas abertas consumir acima de 190Mb?

Mozilla.. Reestruture e otimize seu software enquanto a tempo!

Idéias para futuro Visual do Firefox 3.7 e 4.0

Talvez alguns discordem do que vou escrever, mas… pelo menos para mim, depois de um software ter um grande amadurecimento, chega-se o momento de se trabalhar na aparência, no visual, no desenho, na interface para com o usuário. E, depois de grandes novidades, correções de bugs, chegou a vez do Mozilla Firefox pensar a respeito disto.

O que se vê, é que os desenvolvedores buscaram se inspirar e muito no tema Aero do Janelas® Vista/7. Percebe-se, pelas imagens disponibilizadas, que algo peculiar do Ribbon (inserido n o Microsoft Office 2007, e agora também em aplicativos como a calculadora, Wordpad e Paint no 7), também terá uma pontinha presente no Firefox 3.7 e também no Firefox 4.0., nada tão exagerado.

Vejamos a versão esperada para o Firefox 3.7:

A redução na quantidade de informações visuais dos botões de funções, é um salto, tanto quanto esperado. Também vemos, que reinventar a roda, é perca de tempo, e o botão “Tools”, diz claramente de onde que veio tal ideia: (É… isto mesmo que o leitor está pensando) Um misto de Chrome com Internet Explorer 7/8.

Isto não é de todo mal, mais é bem possível que muito usuários não gostarão disto.

Se você não possui uma placa gráfica muito boa, e que a mesma não roda efeitos de transparência, é bom ver que também, o visual sem o Aero, também possui muitas linhas agradáveis se comparada diretamente com a com Aero Glass. Os botões, também, continuam com um visual 3D.

Prá quem usa o Windows XP, também não esqueceram, e o que se vê… é uma simbiose do Firefox 3.7 entre os diferentes sistemas operacionais da Microsoft, tendo, praticamente, uma identidade visual única e ao mesmo tempo, diferenciada.

Para o Firefox 4.0, vemos uma modernidade ainda maior entre um e outro desenho.

Também, vemos como a inspiração no Chromium do Google, está sendo, uma das grandes influências para estes futuros updates visuais do Firefox… tais como eliminação dos famosos menus como o conhecemos (Arquivos, Editar, Exibir, Histórico…), sendo que tudo ficará integrado e acessível de uma forma mais… digamos… simplistas como no design do 3.7, e com os botões de ações, ainda mais reduzidos em quantidades padrões.

Os botões de parar e recarregar páginas, se integram em um único botão menor no lado direito da barra de endereços, eliminando espaço e limpando o ambiente. O botão “Home”, também ganhou um novo estilo, ficando ao lado da barra de abas, onde também, possui uma entidade redesenhada para se ver as páginas abertas e carregadas… talvez com um “q” a mais do qual desconhecemos ainda.

Neste último, acabamos por ver o que o Chromium mostrou ao Firefox… limpeza… esta é a palavra chave!

Apesar destes dois últimos exemplos, tenho que dar minha pitada de crítica, e dizer que um estilo de mistura entre os dois, seria o ideal. Como?

Pois bem… pegue a transparência da janela, e aplique-a a barra de abas e barra de endereços e chegaremos próximo ao estado da arte. =)

Elimine aquele botão na barra de endereços escrito “Google” e estará acabado. Bom mesmo é ter os dois designs para se escolher na hora da instalação ou após a mesma.

Estas telas podem ser obtidas no wiki da Mozilla, sendo os links a seguir:

https://wiki.mozilla.org/Firefox/3.7_Windows_Theme_Mockups

https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups

O que fica devendo?

Ahh.. é claro!

Ainda não surgiram nenhum desenho de janelas destas futuras versões do Firefox para nenhum outro sistema operacional, algo que, acredito, em breve mudar.

Com a experiência adquira no Firefox 3.5 nos sistemas Linux, e vendo o comportamento visual em ambientes tais como Gnome e KDE e a integração com o tema utilizado pelo usuário, é claro que o web browser, não ficará devendo para outros sistemas. Pois, já sabemos do potencial do navegador e sua integração com o Linux.

No Mac OS X, é claro.. terá o Aqua, e olhando os Mockups visuais do Firefox 3.7 no Windows XP, é substancial termos uma ideia de como ele se comportará nas maçãs mordidas.

Sempre é bom haver renovações, e uma delas, pelo meu ponto de vista, seria utilizar algo similar ao que ocorre com o Koffice 2.0… as chamadas área Acopláveis, trazendo novas funcionalidades e quem sabe até ocultar outros recursos.

E aqui fica meus dois centavos de contribuição para a divulgação destes novos ideais da Mozilla para que o Firefox conquiste cada vez mais espaço e o coração dos internautas.

E você? O que achou?

Deixe sua opinião =)

Google Ghrome para Linux utilizará GTK+

Uma das principais críticas que o navegador web Google Chrome tem recebido até o momento, é por ainda não estar disponível para qualquer outra plataforma se não o Windows. O Google prometeu entregar Chrome para Mac OS X e Linux, mas como nem tudo ocorre como o esperado, está um tanto quanto difícil de se desenvolver, antecipando a interface do Google Chrome, explicou Ben Goodgear em um e-mail. Também foi revelado que a versão do Chrome para Linux, utilizará a toolkit Gtk +.

A decisão de utilizar uma toolkit nativa para gerar a interface do usuário em cada plataforma tem feito tudo ficar mais difícil e demorado para se entregar as versões do Chrome para o Mac OS X e Linux.

Várias pessoas perguntam de o por que o Google não utilizar apenas a Qt e pronto, fazendo todo o processo em um único lote, tornando as coisas mais fáceis. Goodger explica que o Google “[evita] plataformas cruzadas em seus projetos de Interface com o usuário, pois enquanto eles podem oferecer aquilo que aparentemente possa parecer ser um caminho rápido na busca de uma UI nativa em uma variedade de plataformas alvo, acaba sendo um tanto quanto mais problemático quando você se aprofunda mais no projeto“. Suas requisições, soam como que “pedindo e falando em outro idioma“, acrescenta. Além disso, Goodger alega que usando algo parecido com Qt “limita o que pode-se fazer a subconjuntos menores comuns que são suportados  e enquadrados em cada plataforma.”

Quanto à versão Linux, o Google inicialmente pensava em um clone da versão para Windows como aceitável, uma vez que o próprio Chrome já está usável como aplicação. No entanto, as pessoas que trabalham sobre a versão Linux do Chrome, fizeram questão de usar a GTK + em vez dessa “ideia”, o Google aceitou tal opção. Desde seu nascimento o Chrome é open source, ele poderá ainda, possívelmente ser desenvolvida uma versão em que utilize-se da toolkit Qt  de uma forma independente do Google, é claro.

Quando se trata da versão do Mac, Goodger explica que o plano vem sendo desenvolver uma versão nativa como um todo. “Uma cópia da versão Windows, definitivamente, também não é aceitável no MacOS X”, afirma Goodger, “onde as APIs para desenvolvimento de interfaces são altamente evoluídas e existem muitas características proeminentes. Então, esse é e sempre foi o plano.“

A versão para Mac está chegando a um prazo tolerável, e espera-se que o Google, entregue as duas versões (Linux e Mac) em meados de Junho deste ano.

Boas notícias, será o implemento de algo parecido com a extensão NoScript do Firefox, pois, de acordo com alguns usuários, este é o modelo de segurança ideal que ainda está faltando.

Fonte: Artigo originalmente de Thom Holwerda, traduzido livremente de http://www.osnews.com/story/20980/Linux_Version_of_Chrome_To_Use_Gtk_