Cinnamon 2.0 deverá abandonar o Gnome

[abdo]

GNOME forever. Sem mais.

Irei dizer o mesmo quando for possível ter a mesma otimização de espaço que o Unity permite!

Até lá ficarei à espera

Openbox forever or while I have a old machine...

[Exploit]

sou fã incondicional do cinnamon

[marcos.vargens]

Pois é, falou tudo, o Gnome 2 parecia uma bala. E eu estou esperando o 3 virar uma bala a cada versão nova, e ao invés disso, percebo ele mais lento. Também prefiro a usabilidade do Gnome3 ao KDE, mas ele consegue ser mais lento que o Windows para abrir aplicativos e renderizar telas, ícones e etc. E pelo visto a Gnome realmente está mais preocupada com o Gnome-Shell do que com a performance do resto. Por isso gostaria de ter outra alternativa. Uma que tivesse a usabilidade do Gnome com a velocidade do KDE . Sonho meu, mas ainda fico encucado de como as melhorias no GTK3 pioraram a performance referente ao GTK2. Chamar isso de melhoria parece meio estranho. Eu achava que as coisas se acertariam com o tempo, mas não está acontecendo.

[Luis Cardoso]

O unity não abandonou o Gnome, bem lembrado mas mesmo assim ele não é um fork. Atenção nas comparações pois o unity é apenas um shell que executa sobre o Gnome, assim como GnomeShell e Cinnamon.

Só um reparo, o Unity não é apenas um shell que executa sobre o Gnome, executa sim sobre o Compiz, estando apenas dependente de aplicações Gnome, mas não é como o Gnome-shell e muito menos como o Cinnamon. Na realidade o Unity é construído com ajuda da NUX Framework, que lhes permite criar toda a shell sobre o Compiz. Por sua vez, o Compiz lida com o OpenGL e X Server. Por outro lado, o Gnome-shell faz uso do libmutter para lidar com o OpenGL (Clutter) e X Server (Metacity). No início, o Cinnamon também dependia da mesma lib, mas actualmente possui as suas próprias, criando um fork do limutter, ao qual deram o nome de libmuffin.

Antes fosse como o Gnome-shell e Cinnamon, metade dos problemas do Unity sumiam desse jeito.

[Luis Cardoso]

Pois é, falou tudo, o Gnome 2 parecia uma bala. E eu estou esperando o 3 virar uma bala a cada versão nova, e ao invés disso, percebo ele mais lento. Também prefiro a usabilidade do Gnome3 ao KDE, mas ele consegue ser mais lento que o Windows para abrir aplicativos e renderizar telas, ícones e etc. E pelo visto a Gnome realmente está mais preocupada com o Gnome-Shell do que com a performance do resto. Por isso gostaria de ter outra alternativa. Uma que tivesse a usabilidade do Gnome com a velocidade do KDE . Sonho meu, mas ainda fico encucado de como as melhorias no GTK3 pioraram a performance referente ao GTK2. Chamar isso de melhoria parece meio estranho. Eu achava que as coisas se acertariam com o tempo, mas não está acontecendo.

Na minha opinião, o GTK3 melhorou na óptica do programador, já na do utilizador... Ainda é preciso polir algumas coisas, pois por vezes surgem alguns problemas e que também podem estar associados a essas lentidões.

É como eu já referi muita vez (em debates com o Cláudio , porque nós temos visões diferentes no que toca a este assunto, ele defende o software e eu o hardware), o que é bom para o programador, é precisamente o que é péssimo para o computador. Ora, todas estas API's melhoradas/refinadas vêm comprovar isso mesmo, quanto melhor forem para os programadores, permitindo-lhes fazer aplicações em poucas horas quando antes levariam semanas, acabam por trazer pedaços de código redundante, acabando por obrigar o CPU a estar a trabalhar quando na realidade ele não está a fazer nada de útil. Acaba por carregar alguma tralha extra que acaba por nem chegar a usar, ou muito raramente é usada!

Quando eu comecei a estudar linguagens de programação (neste caso, comecei com C), aprendi com professores que possuem formação em Informática, como tal aprendi a declarar todo o tipo de variáveis logo no início do código. Conforme fui evoluindo nos estudos, a minha compreensão do C evoluiu, de tal forma que comecei a incluir as declarações pelo meio do código, até porque não fazia sentido estar a declarar uma variável que apenas poderia ser necessária em determinado troço e em determinada condição. Com isto passei a poupar recursos e a tornar o tempo de execução mais rápida.

Uma das razões que me afastam um pouco dos programas para end-user é precisamente por não poder fazer algumas das optimizações sem levar com erros no compilador (já cheguei a escrever alguns troços em ASM no código em C, porque o C não me permitia fazer algumas daquelas coisas de forma tão optimizada).

[Claudio Novais]

É como eu já referi muita vez (em debates com o Cláudio , porque nós temos visões diferentes no que toca a este assunto, ele defende o software e eu o hardware), o que é bom para o programador, é precisamente o que é péssimo para o computador. Ora, todas estas API's melhoradas/refinadas vêm comprovar isso mesmo, quanto melhor forem para os programadores, permitindo-lhes fazer aplicações em poucas horas quando antes levariam semanas, acabam por trazer pedaços de código redundante, acabando por obrigar o CPU a estar a trabalhar quando na realidade ele não está a fazer nada de útil. Acaba por carregar alguma tralha extra que acaba por nem chegar a usar, ou muito raramente é usada!

Nunca disse o contrário disto.

[Luis Cardoso]

É como eu já referi muita vez (em debates com o Cláudio , porque nós temos visões diferentes no que toca a este assunto, ele defende o software e eu o hardware), o que é bom para o programador, é precisamente o que é péssimo para o computador. Ora, todas estas API's melhoradas/refinadas vêm comprovar isso mesmo, quanto melhor forem para os programadores, permitindo-lhes fazer aplicações em poucas horas quando antes levariam semanas, acabam por trazer pedaços de código redundante, acabando por obrigar o CPU a estar a trabalhar quando na realidade ele não está a fazer nada de útil. Acaba por carregar alguma tralha extra que acaba por nem chegar a usar, ou muito raramente é usada!

Nunca disse o contrário disto.

± Mas tu defendes a sua utilização! Já eu...

Basta mencionar duas palavras:

• Java
• Quickly

E já temos discussão aberta! Não é verdade Cláudio?

[Claudio Novais]

Claro que defendo. Se não defendes, provavelmente pertences Àquele grupo de utilizadores que preferiria viver num mundo digital completamente retrógrado simplesmente para aplicar os seus ideais. Exemplo disso foi o Linux durante muitos anos e é ainda o Hurd. Há muitos outros exemplos.

Sem modelação muita coisa é complicadíssima de manter. Já para não falar no desenvolvimento.

[Luis Cardoso]

Claro que defendo. Se não defendes, provavelmente pertences Àquele grupo de utilizadores que preferiria viver num mundo digital completamente retrógrado simplesmente para aplicar os seus ideais. Exemplo disso foi o Linux durante muitos anos e é ainda o Hurd. Há muitos outros exemplos.

Sem modelação muita coisa é complicadíssima de manter. Já para não falar no desenvolvimento.

Pois, mas este tipo de conceito poderia ser feito de raiz, mas não é isso que se verifica, e é por isso que depois vemos os PC's a arrastarem-se... E é por isto mesmo que a minha opinião difere da tua! Eu não pertenço «Àquele grupo de utilizadores que preferiria viver num mundo digital completamente retrógrado simplesmente para aplicar os seus ideais», até porque já comecei -- em tempos -- a fazer algo do género, mas a fazer de raiz, não andando a pegar em coisas feitas (só não continuei, por falta de tempo e porque decidi investir um pouco na informática). Até porque, aquilo que tenho feito, é mais ao género de coisas como a BIOS e similares!

[Claudio Novais]

Aí é que está a coisa, claro que fazer uma pequena coisa super otimizada é muito bonito. A questão é a visão de escalabilidade que te falta. Num mundo prático isso é irreal.

Fazes lembrar muitos alunos (normalmente de engenharias) que pensam que a aplicação de testes físicos exatos nas máquinas têm um sucesso perfeito. Não, quando estamos a falar de uma escala grande as coisas mudam.

E sobre a otimização, não falo da otimização "à lá slackware/gentoo" que tu és adepto. É muito bonito isso, mais uma vez, mas esse tipo de otimização, direcionada a cada hardware transformaria um repositório de uma distribuição em algo centenas ou milhares de vezes maior para trazer todas as ISOs possíveis e imaginárias. Isso ou então teríamos ISOs carregadas de kernels alternativos ou então simplesmente esperaríamos 4 ou 5 horas (ou mais!!) pela instalação do sistema que estava a compilar o Kernel.

Sobre esse tipo de otimizações que sei que és adepto não faz qualquer sentido.

Sobre as otimizações que gostavas de ter nas facilidades aos programadores, claro que aí concordo contigo. Mas elas têm de existir, caso contrário o desenvolvimento de um sistema operativo é algo tremendamente complicado (já o é mesmo assim!). Agora o que se podia melhorar é no ato de compilação, em que, por exemplo, todo o encapsulamento aplicado nas linguagens POO seria desmontado em simplificações. Mas lá está, voltamos a situações utópicas, pois é necessário ter um controlo muito grande entre otimizações de situações normais e de situações de "aplicação de engenharia" por parte do programador.