Cinnamon 2.0 deverá abandonar o Gnome

[Xterminator]

Não sei como o java veio parar nessa conversa mas não discuto esse assunto com o Luiz. Simplesmente não da. Mas o java não é lento (depende com o que vamos comparar), por ser fácil. O java é lento por ser multi plataforma (vm). Discordo de você quando diz que a lentidão se da pela facilidade. Sabe me dizer se o kde ou o QT em sí, é mais difícil do que o gtk? pq mais rapido ele é.

Ou seja o Java pode ser lento, mas o GTK3 que além de ser multiplataforma tem algumas centenas de bindings não pode ser?
Lembre-se ao falar de GTK esqueça-se de Linux, pois vai muito além disto, começe olhando as licenças do seu Smartphone ou da sua TV, depois me diga se ainda concorda com o que foi dito no fórum anteriormente, que a Canonical e o Ubuntu trouxeram as empresas para o Linux, a maioria das empresas citadas por você já contribuiam com *NIX/GNOME e a Canonical só pegou carona no sucesso do Projeto GNOME.
Quando falamos GNOME, não falamos do desktop e sim da plataforma de desenvolvimento.
A idéia de se ter uma Distribuição simples "para seres humanos" foi do Projeto GNOME, então as críticas que vejo hoje, eu já ví no passado, e voltarei a ver no futuro, pois eu sou um usuário GNOME e entendo o que o projeto significa.

[Claudio Novais]

Pronto, e então com o ficheiro HEX, que todos os programas têm essa "estrutura" de instruções, como pensas conseguir ultrapassar essa coisa obsoleta?

Ok, tu quando estavas a falar do ficheiro binário, não estavas a falar do binário puro, pois não? Estavas a falar dos executáveis para correr no SO, correcto? Se usas o gcc para criares uma aplicação para um SO, não estás a produzir um binário puro, caso contrário, um simples indicador, teria perto de 100MB. O próprio SO possui um interpretador que dá as instruções correctas, face ao que está escrito no executável. Os binários puros que tens, são aqueles que são responsáveis pelo arranque do teu SO, quando a BIOS leva o CPU a atingir o MBR. Caso fosse binário puro, o executável criado em Windows, poderia correr em Linux sem necessidade de Wine.

Não Luís, não é assim.

Tu estás a confundir utilização de bibliotecas do kernel com abstração de por parte do Kernel. Segundo o que dizes (negrito), os programas não são binários executados pelo processador mas sim binários lidos pelo kernel (ou algo assim que tu tás a misturar erradamente). Na verdade, o Kernel trabalha em conjunto sim, primeiro no escalonamento, e portanto uma boa percentagem do tempo (falando de um single-core para simplificar) de processamento do processador fica para o Kernel (mas isto é indepenten); e segundo na utilização de bibliotecas do sistema, nomeadamente uma das mais conhecidas o stdio para comunicação com inputs.

Mas isto que eu disse não quer dizer rigorosamente nada de execução sobre um kernel, ou interpretação do mesmo. O Binário é puro sim, mas se utilizar bibliotecas, como é óbvio, vai ter gotos para essas bibliotecas. Se quiseres fazer uma brincadeira, compila com o GCC um pequeno programa que com um ciclo e somar o número de iterações, sem stdin. Se fores ver o que acontece é que o binário vai ter apenas instruções de utilização do processador e da memória (cache) do processador. Kernel? Ele vai continuar a ser usado e se o ciclo for grande, o processo vai estar a ser parado e executado novamente, através do escalonador do kernel que, sim, usa hardware para interrupção.

Portanto, em suma, o que dizes simplesmente está errado. Utilização de bibliotecas é uma coisa. Binário é outra. Claro que se um binário usa bibliotecas acaba por fazer uso delas, e depois? Falando das bibliotecas também, e voltondo a espicaçar, sugeres então que as bibliotecas sejam replicadas duas ou 3 vezes para ter compatibilidade com duas ou 3 arquiteturas mais conhecidas? Ou sugeres que as bibliotecas sejam todas de 8 bits para serem compatíveis para todo o sempre em termos de hardware?

[marcos.vargens]

Ou seja o Java pode ser lento, mas o GTK3 que além de ser multiplataforma tem algumas centenas de bindings não pode ser?
Lembre-se ao falar de GTK esqueça-se de Linux, pois vai muito além disto, começe olhando as licenças do seu Smartphone ou da sua TV, depois me diga se ainda concorda com o que foi dito no fórum anteriormente, que a Canonical e o Ubuntu trouxeram as empresas para o Linux, a maioria das empresas citadas por você já contribuiam com *NIX/GNOME e a Canonical só pegou carona no sucesso do Projeto GNOME.
Quando falamos GNOME, não falamos do desktop e sim da plataforma de desenvolvimento.
A idéia de se ter uma Distribuição simples "para seres humanos" foi do Projeto GNOME, então as críticas que vejo hoje, eu já ví no passado, e voltarei a ver no futuro, pois eu sou um usuário GNOME e entendo o que o projeto significa.

você não entendeu o que eu disse e ainda levou a conversa para um outro lugar.
O Java é interpretado, roda sobre uma Virtual Machine e isso já o torna mais lento por mais que ele se esforce. E o Java é 100% multiplataforma. Você não precisa compilar o fonte para um determinado SO. O mesmo binário roda em qualquer plataforma que ele esteja disponível. O GTK até onde sei não. Ele precisa ser compilado para a plataforma específica. (Me corrija se eu estiver errado por favor), então não podemos dar o desconto da VM nesse caso e sinceramente, por mim ele só rodaria no mundo Unix (mas uso o Gimp no Windows). E o java nem em sonho se propõe a ser um gerenciador gráfico como o Gnome, então sua lentidão é de certa forma compreensível dentro do seu contexto, o qual não se encaixa aqui e veja que questionei o por que de ter sido citado, mesmo entendendo o que o do Luiz quis dizer.
Quanto as críticas, eu reclamo de tudo que acho que não está bom, mas de forma alguma tiro os méritos do projeto Gnome. Se não fosse ele talvez nem usaria linux, pois como já disse, não me adaptei ao KDE, agora ficar cego e não enxergar os seus problemas, ou concordar com tudo, sinto muito mas não vou fazer isso, mesmo sendo usuário dele. Não estou gostando dos rumos que o projeto está tomando e não gosto da lentidão do GTK3. Mas você não é obrigado a concordar comigo.

[José Craveiro]

Talvez vá agora abordar uma questão (ou um conjunto delas) um pouco fora do último contexto; resolvi testar hoje o Cinnamon (a última vez talvez há um ano) e reparei que era a versão mais recente.
Como utilizo a versão 12.04 do ubuntu, antes de baixar o descktop até pensava que só vinha uma versão anterior do mesmo tal como infelizmente acontece com o gnome shell que no meu caso não passa da 3.4 mas ainda assim uso-o em conjunto com o xfce.
Mas falando do Cinnamon achei-o um tanto pesado na ram e também algum arrastamento na abertura e fecho de janelas/programas, coisa que da última vez que o usei não acontecia!
Reparei que algumas alterações surgiram no gestor de definições e alguns pontos negativos (na minha opinião) deixaram-me um pouco desiludido quanto à distribuição dessas definições, a aparência por exemplo, antes este campo era mais completo e intuitivo, entre outros pormenores, mas o pouco que vi, no seu conjunto, não me agradou de todo, achei melhor a desde a versão 1.4!
Será isto o reflexo de uma preparação do projeto a funcionar sem o gnome shell?

[Claudio Novais]

Pois, relativamente à última pergunta não sei José. Mas de facto ele precisa de uma lufada de ar fresco na usabilidade. Sobre ser lento, não acho que seja, até pelo contrário. EU acho que o ambiente em si é muito fluido. O maior problema dele, e acho que é por isso que você tem essa noção, está no menu! Ele é tremendamente pesado, já parece o Dash do Unity.

Sobre o Cinnamon funcionar nas várias versões do Ubuntu, isso é ótimo. Isso é dos maiores entraves que vejo no mundo do Ubuntu e que detesto ver. O Unity é um pequeno exemplo numa imensidão de exemplos que posso descrever os maiores: Gnome-Shell (como você referiu), LibreOffice, GKT em geral, Chromium, são alguns dos exemplos mais importantes.

Sobre a usabilidade, realmente há várias coisas que não gosto. As configurações são demasiado cruas (apesar de ter praticamente tudo). O maior ponto que gosto do Cinnamon é a gestão de áreas de trabalho, que não só mostra todas elas como mostra também as várias aplicações ao mesmo tempo. Algo que o MacOS faz há muito mas que o Unity por exemplo não. O Gnome-shell tem uma construída nessa funcionalidade, a própria shell, mas sinceramente não acho que seja tão boa como o Cinnamon nesse aspeto.

[José Craveiro]

Talvez seja o menu cujo funcionamento roube a desejada fluidez no resto que eu pelo menos notei. Isto comparado com o gnome shell que uso neste momento, o cinnamon que agora experimentei estava a usar em média mais uns 30MB de ram. Só posso comparar com o que antes acontecia numa versão anterior.

[Claudio Novais]

Eu como não o utilizo (apenas experimentei há meses quando saiu a última versão do Cinnamon) não sei dar informações com precisão. Até porque não gosto de ambientes clássicos. Apesar de toda a vida ter utilizado ambientes assim, com o menu, hoje em dia não gosto. Acho uma perda de tempo completa quando pelo teclado se consegue abrir qualquer aplicações com 3 ou 4 teclas (muitas vezes apenas 3: super, letra, enter).

Sobre o uso de memória, também pode estar influenciado pelo tema/ícones. Os ícones do Gnome são bastante otimizados, simples, e portanto devem ter tamanhos muito pequenos.

[José Craveiro]

Cláudio, a menos que os ícones no cinnamon tenham uma execução mais sobrecarregada porque no gnome shell uso os mesmos ícones "da família faenza" e o comportamento não mostra indícios disso. Há ali um consumo a meu ver excessivo e se vermos as coisas, no que toca ao facto de ser um descktop de características mais clássicas em relação ao gnome shell, este último teria mais razões para ter este comportamento, bom, felizmente não é isso que se passa!

[Claudio Novais]

Eu só avisei que podia ser pois recordo-me que quando tinha o computadora anterior ao meu atual o Nautilus sofria de uma maior lentidão no cold-start quando usava ícones com muito boa qualidade. Era só por causa disso!

[Luis Cardoso]

Não Luís, não é assim.

Tu estás a confundir utilização de bibliotecas do kernel com abstração de por parte do Kernel. Segundo o que dizes (negrito), os programas não são binários executados pelo processador mas sim binários lidos pelo kernel (ou algo assim que tu tás a misturar erradamente). Na verdade, o Kernel trabalha em conjunto sim, primeiro no escalonamento, e portanto uma boa percentagem do tempo (falando de um single-core para simplificar) de processamento do processador fica para o Kernel (mas isto é indepenten); e segundo na utilização de bibliotecas do sistema, nomeadamente uma das mais conhecidas o stdio para comunicação com inputs.

Mas isto que eu disse não quer dizer rigorosamente nada de execução sobre um kernel, ou interpretação do mesmo. O Binário é puro sim, mas se utilizar bibliotecas, como é óbvio, vai ter gotos para essas bibliotecas. Se quiseres fazer uma brincadeira, compila com o GCC um pequeno programa que com um ciclo e somar o número de iterações, sem stdin. Se fores ver o que acontece é que o binário vai ter apenas instruções de utilização do processador e da memória (cache) do processador. Kernel? Ele vai continuar a ser usado e se o ciclo for grande, o processo vai estar a ser parado e executado novamente, através do escalonador do kernel que, sim, usa hardware para interrupção.

Portanto, em suma, o que dizes simplesmente está errado. Utilização de bibliotecas é uma coisa. Binário é outra. Claro que se um binário usa bibliotecas acaba por fazer uso delas, e depois? Falando das bibliotecas também, e voltondo a espicaçar, sugeres então que as bibliotecas sejam replicadas duas ou 3 vezes para ter compatibilidade com duas ou 3 arquiteturas mais conhecidas? Ou sugeres que as bibliotecas sejam todas de 8 bits para serem compatíveis para todo o sempre em termos de hardware?

Aquilo que está em negrito revela desconhecimento por parte do funcionamento de um processador. Cache? Sabes para que serve? Se tu pensas que o ficheiro binário que produzes vai interagir directamente com o hardware, estás muito enganado, porque se assim fosse, só poderias partilhar esse binário com quem tivesse um computador exactamente igual ao teu. Principalmente se tiveres uma aplicação gráfica!

E volto a dizer, eu não sugiro que haja bibliotecas replicadas, tu sim.

Só te digo isto, adquire um Arduino, Launchpad, etc, programa e depois vem falar comigo quando souberes como se lida com um CPU! Ah, só uma dica, esquece o <stdio.h>, porque um simples printf, enche-te a memória toda (aquela em que se aloja o programa)!