Repositórios YAST: Se alguém souber de algum para poder atualizar o SUSE, posta ae...

VLW!

repositório para o yast: ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/supplementary/KDE/update_for_10.0/yast-source

É possível testar o KDE 3.5: É possível testar o KDE 3.5 (RC 1 no caso) através de um live CD:

ktown.kde.org/~binner/klax/devel.html

:
Ja estou baixando...a cada versao o KDE fica melhor !!! Alias que for baixar pro Slackware abaixo esta um dos links disponiveis.

http://mirror.cc.columbia.edu/pub/software/kde/stable/3.5/contrib/Slackware/


[]
Ricardson Williams

e pra Debian??: Salve,

Tenho uma versao do Kalango 3.1, 'Based in Debian', e gostaria de colocar o KDE 3.5 nele, como eu faço? Entrei no site e me perdir legal.

Valeu!!!

Boas notícias: Muito trabalho a frente. KDE e Firefox novos... Boas notícias...
GoblinX, um livecd nacional baseado no Slackware

Debian: Kalango e Kurumin não são Debian, são baseadas em Debian. Procure os responsáveis por essas distros e pergunte a eles.

Acho que você se enganou: Acredito que você não tenha visto que ele mesmo disse que é baseado, contudo logo estarei postando no fórum do Kalango uma dica de como atualizar o KDE.

KDE => Gnome: Sou usuário do KDE desde de conheci o Linux e sempre achei ele mais completo e com maior usabilidade do que o Gnome. Porém, depois que conheci o Gnome fiquei apaixonado pela simplicidade e rapidez... No entanto, fazendo testes empíricos pude perceber que o Gnome e o KDE usam a mesma quantidade de memória, além de ter comprovado minha experiência numa revista especializada! Então fica a minha pergunta:

Por que o Gnome sendo muito mais simples e minimalista que o KDE ainda consome tanta memória quanto ele?

È realmente notável que o Gnome é mais simples e mais rápido que o KDE, vide a execução do "gnome-terminal" x "konsole" por quem têm dúvidas, então porque o Gnome ainda carrega tanta memória?!


A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

Compilar do ZERO: Acho que vou logo ser obrigado a compilar todo o KDE para incluir algo mais... a cada dia começo a compilar mais e mais pacotes.
GoblinX, um livecd nacional baseado no Slackware

Ué: Ele deve usar mais memória pq carrega todos os aplicativos/bibliotecas na memória, e exatamente por isto o gnome-terminal abre mais rápido.


_______________________________________________________________

"Só sei que nada sei" Sócrates

"O Homem está condenado a ser livre" Jean Paul Sartre

Konqueror: Pois é.

Alguém ai sabe se já dá para ver o Gmail com o konqueror, tipo, com todos os recursos do Ajax.

_______________________________________________________________

"Só sei que nada sei" Sócrates

"O Homem está condenado a ser livre" Jean Paul Sartre

Quanto ao GMail não sei, mas: Quanto ao GMail não sei, mas o Konqueror tem um suporte bem legal à classe XMLHTTPRequest (usada no Ajax).

Minha biblioteca de Ajax+PHP (www.sourceforge.net/projects/cajax) quase toda funciona nele sem problemas...

SSH no Konqueror: Recentemente descobri uma função nova no Konqueror. A partir de uma máquina cliente é possível acessar um servidor remoto ssh. Basta digitar:

fish://servidor.de.ssh

Achei fantástico :-).

Abraços,
Patrick
Caruaru-PE

Mandriva: Alguém sabe onde tem o KDE 3.5 pro mandriva?

Além de manter boa parte de: Além de manter boa parte de sua estrutura na memória, os aplicativos para gnome são realmente pesados, não existe uma razão para um simples applet de relogio consumir 20M, ou 18M apenas para monitorar a bateria. Esses applets consomem mais do que o gnome-volume-manager responsável pela apreciação de dispositivos mass-storage que são
plugados no sistema.

A primeira vista parece que o GNOME foi feito pensando em aplicativos independentes da suíte sem compartilhar muita coisa em comum senão gtk. Vide gnumeric, abiword, gimp, gftp,... esses aplicativos foram agregados ao suite gnome, mas não são do gnome. O GNOME em sí tem poucos aplicativos próprios do ambiente (ex. nautilus).

Então voce soma e percebe que o gnome é uma coisa, e seus aplicativos agregados são outra. Se voce tiver 256M de RAM o GNOME voa, porém se tiver menos é muito sofrivel sua performance dependendo do que voce for carregar.

O KDE tem muita integração entre seus próprios aplicativos compartilhando memória e reutilizando o que for possivel, por um lado isso é muito bom, pois economiza memória e disco e por sua vez melhora sensivelmente a performance, mas por outro lado faz um lock-in com o kde, por exemplo tente instalar o K3B dentro do GNOME, vai notar que voce praticamente carrega quase um mini-kde só para usar um único programa e ainda vai sofrer com a aparencia estranha dos widgets e tempo de carga maior. O interessante é que o inverso não é verdadeiro, voce carrega aplicativos GTK numa boa no KDE com a mesma performance obtida no GNOME, porque ? porque cada aplicativo gtk é independente do ambiente (em geral). O GNOME não causa nenhum lock-in nos aplicativos GTK independentes. Assim como aplicativos QT independentes também não causariam lock-in, mas é muito melhor criar aplicativos QT no KDE e ser beneficiado provavelmente com dezenas de componentes já desenvolvidos.

O XFCE é tão minimalista quanto o GNOME, a diferença fica apenas por conta dos icones na tela e o consumo não é tão gritante. O problema é que usabilidade do GNOME é realmente muito boa apesar do consumo de RAM.

ainda não testei: tem alguma coisa aqui sobre repositorios urpmi
ainda nao testei


http://seerofsouls.com/rpm2006.html

É ? De onde veio esta inform: É ? De onde veio esta informação de que o Gnome carrega todos os aplicativos/biblioteca na memória ?

Já testei :): No cooker há um tempão.

Se tiver dificuldade para achar tente o 'Easy Urpmi' (não sei de cabeça a URL).

O Kde é muito horrivel, ele: O Kde é muito horrivel, ele não está acompanhando os quesitos de beleza e sofisticação.
É o mesmo que falar que o slackware é uma versão de verdade do linux!


Fala serio!

lfenciso@gmail.com

nossa, que comentário inúti: nossa, que comentário inútil...

Essa explicação esclareceu: Essa explicação esclareceu bastante sobre as diferenças entre os dois ambientes e tirou algumas dúvidas que eu tinha. Valeu. :-)

URL: http://easyurpmi..zarb.org

Ricardo Rabelo Mota
Site Católico Nossa Senhora Rosa Mística
http://www.rosamistica.org

DIGA NÃO AO ABORTO!

Não entendi suas colocaçõe: Não entendi suas colocações.

Em primeiro lugar, não sabia que existia um padrão de beleza a ser seguido por gerenciadores de software livre. E pelo que me consta, beleza é subjetivo e não segue quesitos pré-determinados, apesar de existirem teorias de que a beleza é uma questão de simetria geométrica e proporcionalidade.

Alguém tem uma referência para algum documento onde posso encotrar algo à respeito dos "quesitos de beleza e sofisticação" citados?

Que eu saiba o Slackware é uma distribuição que utiliza uma versão do kernel Linux, e não "uma versão" do Linux.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

Exato!: Eu sempre bati nessa tecla! Os aplicativos para KDE são realmente muito ligados a ele! É um pena que programas tão bons quanto o K3B e Amarok serem MUITO ligados ao KDE! O Evolution - cliente de e-mail para Gnome - roda perfeitamente bem no KDE, e sem diferenças gritantes em relação ao visual. Agora rodar um aplicativo KDE no Gnome é horrível sob todos os pontos de vista:

- Carrega muita memória!

- Necessário instalar muitas bibliotecas ligadas ao KDE.

- Diferenças gritantes em relação ao visual.

Imaginem que não existe programa melhor que o K3B, e ele é feito para KDE! Acho que programas assim deveriam ser mais independentes do ambiente! Não desconsiderando a qualidade do QT, mas a verdade é que os aplicativos feitos em GTK se integram melhor no Linux, pelo menos sob o ponto de vista de homogeinidade do visual e independência do ambiente gráfico!


A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

Título: Então pq o título "e pra Debian??" ?

Concordo: Sou usuário de Linux há alguns anos e sempre vejo as comparações Gnome x KDE. Todas as distros Linux que usei utilizavam o KDE. Há duas semanas comprei um micro básico na Americanas, Celeron 2.13, 128 mb, para colocar em casa, para as crianças acessarem a net, fazer trabalhos, etc... Falei pros meus filhos (um de 11 anos e um de 6) que no micro só teria Linux. Então eles me pediram pra colocar uma versão do windows, para que eles pudessem jogar (the sims, medal of honour, etc...). Conseguiram me convencer. Mas disse que a eles que o Windows seria só pra jogar. As demais coisas seriam feitas no Linux. Resolvi instalar/testar o Ubuntu. Resumindo a história: após duas semanas de usos do micro as crianças só falam uma coisa: "tudo no Linux é mais lento, no windows é muito mais rápido". O Ubuntu com Gnome em 128 mb de Ram, fica uma carroça, muito lento. Em termo de desempenho não dá nem pra comparar com o XP ou o KDE. Não vejo a hora de comprar 512 mb de memória Ram. Que venha o 13°!!!

gmail: funciona perfeitamente, mas para isso tem que forçar o konqueror a se identificar como firefox e também a usar a visualização padrão ao invés da html

HUHUHU: ótima notícia!!! eu estava contando os dias para usar esta versão. Sempre usei KDE e sempre me surpreendo com os avanços alcançados com ele. O time de desenvolvimento está de parabéns !

Agora que venha o 4.0 !: Agora que venha o 4.0 !

Suposição: Eu disse "deve".

_______________________________________________________________

"Só sei que nada sei" Sócrates

"O Homem está condenado a ser livre" Jean Paul Sartre

KDE: Ótima notícia, eu adoro KDE. :-)

Certo, Desculpe entao!: Salve,

Eu mostrei que é baseado no Debian, desculpe pelo titulo, ja que tem confusao. Todos quando falam do Kurumin, Kalango,..., falam BASEADO NO DEBIAN, certo?! Se serve no DEBIAN, provavelmente servira nessas distros?!


Valeu!!!

A resposta é: A resposta é não. Vai depender de caso a caso. O Kurumin, por exemplo, usa bastante coisa da unstable. Então, você terá que pegar os pacotes da unstable, que não é o release oficial do Debian.

Instale o KDE pra Ubuntu: Bom, como um teste, v. poderia instalar o KDE pra ubuntu. Basta instalar o pacote kubuntu-desktop e ver se ele se sair melhor com esta quantidade de memória. Meu palpite é que não há muita diferença. Venhamos e convenhamos, é pouca memória.

Discordo do problema do visual: Se as aplicação GTK/Gnome tem um visual razovelmente integrado com o KDE é por que o pessoal do KDE se preocupou com isso, procurando pelo menos aplicar as cores do KDE às aplicações GTK. Além disso, há outras iniciativas como o gtk-qt que tenta deixar o visual de aplicações GTK semelhantes as do KDE. Detalhe, no Kcontrol v. pode desativar esta característica e as aplicações GTK ficarão com cores diferentes, etc.

Se a recíproca não é verdadeira, vai ver é por que o pessoal do Gnome não tem interesse em aplicar as cores do Gnome ou a aparência às aplicações QT/KDE. De repente, isso indica que quem usa gnome não gosta de usar aplicações KDE/QT, ou algo assim.

Eu gosto de ambos, mas acho o KDE melhor nesse quesito.

Velocidade: A minha experiência é um pouco diferente da sua:
Tenho um notebook com Win XP e Ubuntu (c/ Gnome) instalados em dual boot, não tem nem comparação... A velocidade com o Ubuntu é muito superior em comparação com a velocidade usando o Windows. Já usei também o Suse 9.2 e 10.0 e achei a velocidade desses dois sistemas (c/ KDE), também muito mais lenta...

Semprom 2.800+
Ram 256M
HD 40G

LIBERDADE, IGUALDADE E FRATERNIDADE!

precisamente: o KDE é estruturado seguindo o modelo Windows de se fazer as coisas: componentes de software agregados via um ORB e rodando em um só processo multithreaded, altamente integrado.

O GNOME utiliza a clássica filosofia Unix de se fazer as coisas: pequenos processos separados interagindo através de técnicas usuais de IPC, como pipes e sockets. Embora ele também dê suporte à componentização através de seu ORBit ( fruto dos esforços do Icaza de seguir a cartilha M$ ), na prática, a maioria dos desenvolvedores GNOME prefere o modelo Unix mesmo. Consome mais memória, mas ao menos em teoria, deveria prover mais robustez...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

karamba!!: "O SuperKaramba agora é incluso no KDE, proporcionando uma boa integração e fácil instalação dos widgets para o usuário do desktop."

Mais bloat inútil!

e eu preferia que o KDE viesse com kmaks ou kim ao invés de kate... ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

suposição: Mas além do "deve", também disse "carrega" e "abre" (ao invés de "deve carregar" e "deve abrir").
Agora entendi que foi uma suposição, mas quem não prestou atenção ali (eu por exemplo) pode ter achado que você estava afirmando aquilo.
Desculpe pela má interpretação :)

Em compensação: O modelo do KDE é mais escalável. No futuro, quando usarmos 300 aplicações ao mesmo tempo em nossos Meganiums XV de 9.49 THz com 400 TB de RAM, as aplicações Gnome 11.0 rodando serão muitíssimo maiores que as aplicações KDE 13.1 rodando. A não ser que o Gnome a essa altura já tenha mudado de paradigma...

Defina "prover mais robustez": Defina "prover mais robustez". :)

webcam no kopete ?: Alguém que ja tenha testado o novo kde ja utilizou o novo suporte a webcam no kopete ? estou curioso pra saber antes de atualizar o meu suse 10.0....

É só não usar o Superkaram: É só não usar o Superkaramba, assim como não uso o gDesklets quando tou no Gnome.

E não me venha choramingar pelo acréscimo no tamanho dos pacotes do KDE decorrentes disso. Afinal, v. mesmo mantém pacotes inúteis instalados por causa do pacote ubuntu-desktop, não? :)

Não recomendo.: Eu andei conferindo e esses RPMs são do RC1.
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca

por exemplo: vc está assistindo a um preview de vídeo embutido em seu Konqueror. De repente, dá um pau qualquer e seu Konqueror fecha, inclusive o vídeo que vc estava assistindo, que estava rodando no mesmo processo.

No GNOME, a filosofia são processos especializados e separados: file browser e video player. Nautilus caiu, mas vc continua assistindo seu vídeo.

Sim, claro, vc pode obter o mesmo comportamento não embutido no KDE, né? Mas aí, já não seria tão "integrado", né?

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

não conte com isso!: Duvido muito. KDE13.0 provavelmente será escrito em managed C++ para mono para melhor seguir o modelo da decadente empresa de marketing Microsoft e o GNOME11.0 ainda em C, mas com diversos bindings, inclusive o mais popular de todos, para Java.

Processos separados com IPC continuarão sendo a norma no mundo *nix como o foram ao longo de 60 anos, enquanto que os seguidores da velha firma de marketing estarão se empenhando ao máximo para dar suporte aos seus instáveis e remendados aplicativos multithreaded com locks e outras primitivas de sincronização macarrônicas espalhados em tudo que é canto...

Enquanto isso, jovens hackers Haskell de 11 anos vão estar se perguntando como sistemas tão complexos puderão ser construídos com ferramentas tão primitivas e cheias de complexas tramas de estado...

Além disso,a despeito de chips implantados em nossos cérebros, não acredito que seremos multitarefa a ponto de prestar atenção à 300 aplicações simultaneamente. :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Ubuntu: agora é só esperar até abril de 2006 quando o Ubuntu terá também suporte ao KDE. Aí sim sera a distro perfeita.

Engraçado, pelo seu argument: Engraçado, pelo seu argumento eu fico tentado a achar o KDE melhor. Se eu quero algo "robusto" eu rodo como aplicação a parte, se eu quero algo "integrado", rodo no preview. Ou seja, eu escolho o que achar melhor. Por sinal, nos mime types do KDE eu posso até escolher o comportamento padrão entre "robusto" e "integrado". hehehe Parece que no caso do gnome, é robustez ou robustez. :) Sendo que a pretensa falta de "robustez" decorrente da integração no konqueror não é algo que ocorra com frequência, na prática. Na verdade, não lembro de um vídeo ter sumido decorrente de um travamento do konqueror. Mas se ocorrer, mudo para o modo robusto num piscar de olhos. :)

Por fim, tenho lá minhas dúvidas se robustez tem a ver com isso que v. exemplificou, se bem que ando meio desatualizado. E dado que qualquer coisa que se quer elogiar vira "robusto" hoje em, é capaz até do meu par de tênis novo ser robusto também e eu não saber.

2 cents: "não uso o gDesklets quando tou no Gnome"

gDesklets não vem com o Gnome.

"mantém pacotes inúteis instalados por causa do pacote ubuntu-desktop"

hmm, malandrinho, hein? Mas pacotes de 414kb não me incomodam. Se me incomodassem, não os manteria.

Estou atualmente usando o Ubuntu como um usuário bobo mesmo. Só tenho aberto o shell pra rodar vim e make mesmo. Por isso não quis mexer no ubuntu-desktop, como um usuário comum. Não tenho mais paciência de manter uma partição /usr/local à parte com meus compilados. Quero pacotes prontos pra uso e por isso, vou respeitar algumas regrinhas de boa convivência com o gerenciador de pacotes... :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Quando chegar essa época, se: Quando chegar essa época, será que já estaremos usando uma versão beta do Hurd ? :)

robustez: Em Informática, robustez siginifica algo sólido, que funciona corretamente mesmo nas adversidades. Processos se comunicando via IPC são em geral encarados como uma solução mais robusta do que multithreading e memória compartilhada, que é mais ágil mas mais suscetível a problemas de locking e race conditions.

Os servidores comuns do mundo *nix funcionam com o modelo de processos. No Windows, são severamente multithreaded. Qual é mais estável, segundo estatísticas?

À propósito, algo que sempre ouvi dizer é que o modelo de processos no Windows nunca foi muito bem desenvolvido e essa é uma das razões para multithreading ser tão usado e abusado...

Problema do KDE é: se vc pôr tudo em processos separados ( mais robusto ), vai começar a consumir mais memória e CPU do que o GNOME. E não acho que vc queira isso, não?

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

sim: mas ele estará no processo de reimplementação para utilização do mais novo projeto de microkernel existente. Vai demorar um pouco, mas vai ser escalável como nenhum outro!

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"gDesklets não vem com o Gno: "gDesklets não vem com o Gnome."

O que importa é se tá rodando e comendo recursos ou não. E o Superkaramba só o fará se estiver rodando, não? :) Pelo, menos, assim o foi quando o testei.

"hmm, malandrinho, hein? Mas pacotes de 414kb não me incomodam. Se me incomodassem, não os manteria."

Tamanho do pacote do superkaramba do Ubuntu: 430 KB. Mais, em distribuiçoes baseadas em Debian, onde se costume criar muitos pacotes binário a partir do fonte, não me espantaria se o superkaramba tivesse seu proprio pacotinho binário pronto a ser desinstalado. Lógico que um usuário poderia deixá-lo por causa do kubuntu-desktop para não quebrar a política da boa convivência com os sistemas de pacotes ...

aí não dá!: "superkaramba do Ubuntu: 430 KB"

aí é demais!! 415kb é meu limite! :))

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"Em Informática, robustez si: "Em Informática, robustez siginifica algo sólido, que funciona corretamente mesmo nas adversidades. Processos se comunicando via IPC são em geral encarados como uma solução mais robusta do que multithreading e memória compartilhada, que é mais ágil mas mais suscetível a problemas de locking e race conditions."

A definição continua a mesma, mas a comparação entre IPC e multitheading me parece meio estranha. Opinião pessoal minha, não li nada que corrobore o que vou dizer. Eu vejo multthreading a serviço de uma aplicação que precisa de mais de uma tarefa executando concorrentemente. IPC me parece mais voltado a aplicações cliente-servidor, aplicaçoes distribuídas (envolvendo CORBA, RMI, sockets, etc.) ou programação paralela (MPI, PVM).

Usar processos no lugar de threads numa aplicação que faz processamentos concorrentes a torna mais robusta? Observe que já há bibliotecas que facilitam a criação de threads, de modo que os problemas que v. aponta me parecem causados por error de programação que tem pouco lugar com o nível de abstração atual. Como usar processos separados faria melhor? Na maioria das vezes não faz sentido o processo que substitui a thread sobreviver, por que normalmente theads são usadas quando o processo não tem significado por si só. Elas executam sua tarefa e retornam o resultado pro processo-pai. Sem processo-pai, não a proposito pra uma thread.

"Problema do KDE é: se vc pôr tudo em processos separados ( mais robusto ), vai começar a consumir mais memória e CPU do que o GNOME. E não acho que vc queira isso, não?"

Num sistema baseado em componentes isso não é necessariamente verdade. O componente é carregado sob demanda. Se eu não usar o preview, pro exemplo, o componente não será carregado (e se ele é implementados com threads, esta não serão criadas), logo não ocupará recursos. Imagino que o pessoal do KDE sabe o que está fazendo e fez direito. :) Claro que um sistema baseado em componentes exige um tipo de biblioteca que consome mais recurso, mas dê uma olhada no consumo de memória de KDE e gnome e não verá essa grande diferença. No Ubuntu/Kubuntu eu não vejo. Quanto a CPU, é dificil comparar projetos diferentes, mas não percebo o KDE dando surra na minha CPU em comparação ao Gnome. E sim, na maioria das vezes eu uso (ou usava, já que estou de férias do KDE) uma aplicação a parte no lugar do preview.

Atualmente voltei a usar o gnome e vejo algumas vantagens de usabilidade nele, mas essa suposta robustez não vejo como um grande diferencial. Mas preciso deixar mais de especular e pôr mais a mão na massa pra ter uma opinião mais decente.

A diferença de suas esperien: A diferença de suas esperiencias pra mim so tem uma explicação, device drivers, provavelmente o notebook tem drivers para linux mais bem feitos que no caso do colega que tem um pc.

ERRATA: Onde se lê: "Sem processo-pai, não a proposito pra uma thread."

entenda-se: Sem processo-pai, não há proposito pra uma thread.

Tem uma montão de outros erros, mas esse eu achei que deixou a frase sem sentido.

Fim do ócio.

Bom, partindo do princípio q: Bom, partindo do princípio que o Icaza é um dos pais do Mono e que tem a intenção declarada de portar o Mono pra .NET, acho que vai acontecer o contrário.

Haskell developer

desperdícios: "aplicação que precisa de mais de uma tarefa executando concorrentemente."

processos e comunicação entre processos é o mesmo que um processo com vários threads e eles se comunicando atráves de áreas de memória compartilhada. Acho que este exemplo vem das manpages Perl e do que me lembre, vai mais ou menos assim:

"Multithreading é como ter vários chefs compartilhando a mesma cozinha para fazer um banquete: vai haver vários conflitos de personalidade, briga pela posse das ferramentas ( garfos, facas, panelas etc ) e pelos ingredientes."

"Multiprocessamento, por outro lado, coloca cada chef em sua própria seção, com suas próprias ferramentas e ingredientes e cada seção fica atarefada com um prato em particular."

A cozinha com vários chefs vai ser bem mais difícil de gerenciar, mas é uma solução mais barata e rápida, pelo compartilhamento de recursos ( que vez ou outra vai causar problemas ). O modelo com várias cozinhas para cada chef vai ser mais fácil de gerenciar, mas mais cara e eventualmente um pouco mais lenta para sincronizar as várias partes, já que a comunicação entre elas é reduzida.

"Usar processos no lugar de threads numa aplicação que faz processamentos concorrentes a torna mais robusta?"

Se a robustez característica de servidores *nix típicos e seu modelo de processos serve de algum indicativo, acredito que sim.

"Observe que já há bibliotecas que facilitam a criação de threads, de modo que os problemas que v. aponta me parecem causados por error de programação que tem pouco lugar com o nível de abstração atual."

Me parece que é um problema inerente ao fato de se usar memória compartilhada do processo para comunicação entre as threads. Sempre ouvi um mantra na faculdade, que sempre se mostrou valoroso: "poucas interfaces, pequenas interfaces"

"Elas executam sua tarefa e retornam o resultado pro processo-pai. Sem processo-pai, não a proposito pra uma thread."

Bem, o mesmo vale para processos-filho: sem um processo-pai, não há sentido.

"Se eu não usar o preview, pro exemplo, o componente não será carregado (e se ele é implementados com threads, esta não serão criadas), logo não ocupará recursos."

Ué, no que isso é diferente de um processo à parte para exibir o vídeo? Se ele não iniciar, também não vai usar recursos. Melhor ainda, quando eu terminar de assistir ao vídeo e fechar o aplicativo, o processo vai finalizar e liberar memória.

O mesmo pode ser dito do componte/plugin, enquanto o processo em que seu thread roda estiver ativo? Acredito que não: depois de carregado, ele vai continuar lá.

Taí a beleza do modelo de componentes da M$: serve para ajudar fabricantes de hardware a vender hardware mais novo e potente por causa dos desperdícios de recursos. Por isso não se vê "Ready for Linux" como label em equipamentos de informática: ele não ajuda a vender hardware melhor... :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

O linux nao escalava bem usan: O linux nao escalava bem usando thread até o aparecimento do NTPL.
Mesmo assim o modelo classico por processo e não por thread tem o seu lugar garantido especialmente serviços sobre internet (inetd). BufferOverflow é muito díficil de diagnosticar em multithreads.

Creio que voces estao comentando a mesma coisa sob bases diferentes, o GNOME nao tem que ser multithread porque nao quer componentização, não vai existir um gnome-runtime, apenas GTK. O time do GNOME só empenha-se na usabilidade e alguns poucos programas que facilitam a vida se fossem integrados como por exemplo gnome-volume-manager (dispositivos USB), gnome-cups (impressora),... o restante cada distro escolhe o que quer empacotar ou nao.

O time do KDE especializou-se numa suíte completa desenvolvida por eles, é quase um sistema operacional polivalente. A distro que usa KDE raramente tem que tirar ou colocar algo, apenas cria um tema.

Sao duas opcoes distintas e nao excludentes.

O KDE tem bom aplicativos o que realmente nao entendo é porque ter que criar seus próprios aplicativos, porque abiword, gnumeric, openoffice, firefox, thunderbird, evolution, gimp,... nao servem ? Já que GTK roda muito bem no KDE, nao entendo a mania do KDE em ser polivalente.

typo: "portar o Mono pra .NET"

espero que vc tenha escrito errado e tentava se referir ao GNOME, senão sua afirmação vai gerar um core dump... :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

porque?!: "porque abiword, gnumeric, openoffice, firefox, thunderbird, evolution, gimp,... nao servem ?"

Ora, porque a Trolltech não ia gostar, é claro!

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"Multithreading é como ter v: "Multithreading é como ter vários chefs compartilhando a mesma cozinha para fazer um banquete: vai haver vários conflitos de personalidade, briga pela posse das ferramentas ( garfos, facas, panelas etc ) e pelos ingredientes."

O legal dessa definifição é que fica fácil de explicar que apareceu um BUG (inseto) no programa, isto é, na cozinha.

Eu já sabia...: Quando comprei o micro já sabia que 128 mb de ram era pouco. Mas não imaginava que ficasse tão lento. Eu imagino que com o acréscimo de 512 mb, que farei em breve, o desempenho fique adequado.
Como o hamacker disse acima:

Então voce soma e percebe que o gnome é uma coisa, e seus aplicativos agregados são outra. Se voce tiver 256M de RAM o GNOME voa, porém se tiver menos é muito sofrivel sua performance dependendo do que voce for carregar.

Instalar o KDE agora não. Além de configurar todo o micro do meu jeito (aplicativos, temas, ícones, etc...) não acredito que o desempenho melhore muito...

"processos e comunicação en: "processos e comunicação entre processos é o mesmo que um processo com vários threads e eles se comunicando atráves de áreas de memória compartilhada."

É aí que eu já acho que não é o mesmo. O fato da memória ser compartilhada num caso e não ser no outro me faz pensar e usar IPC (ou suas imaplemntações mais alto nível) e threads pra coisas não muito relacionadas. E mais, acho que quando uma entra na area da outra, suas pretensas vantangens começam a sumir. Eu quero fazer um programinha que calcula os menores caminhos entre um certo número de vertices de partida e de chegada de um grafo. E quero ver na tela as mudanças nos caminhos escolhidos a medidade que o algoritmo que implementa uma meta-heuritica vai melhorando a respota. Como meta-heurística as vezes demora, quero ter a chance de interromper o processamento. Não vejo como um programa assim precisa ser feito com IPC e como IPC seria melhor que threads. Pelo contrario, como os dados não são compartilhados, ainda se consome espaço de memória com cópias de dados .

Por outro lado, se eu quero fazer um deamon num sistema UNIX que, logicamente, recebe pedidos de um cliente, bom aí eu uso IPC. Ou se eu faço um programa paralelo eu uso IPC, até por que seria meio dificil usar threads neste caso.

Por fim, que eu saiba o proprio KDE usa deamons e, por conseguinte, um tipo de IPC em conjunção com outras tecnologias. Por sinal, usar componentes não sigfica usar threads, ainda mais se todo a aplicação é feita com componentes locais. Mas enfim....

"Ué, no que isso é diferente de um processo à parte para exibir o vídeo?"

A minha argumentação é que o fato da tecnologia existir, não significa que recursos estão sendo disperdiçados antes de usá-los. Não foi essa a sua critica? Se eu usar o lado "robusto" do KDE, eu vou disperdiçar recursos com o lado "integrado" que eu não tou usando? O que argumentei foi que isto não é necessariamente verdade. Eu não tou argumentando que o funcionamento é diferente . :)

"Se ele não iniciar, também não vai usar recursos. Melhor ainda, quando eu terminar de assistir ao vídeo e fechar o aplicativo, o processo vai finalizar e liberar memória."

Ah! mas aí estamos no modo "integrado", que deixa o recurso por ali, como quem não quer nada, pra carregar mais rápido quando for usado mais adiante. Senão gosta, escolha o modo "robusto". O poder da escolha. :)

Minha máquina no tabalho tem 1.5G de memoria RAM (candidata a modo "integrado"). Minha maquina domestica tem 256MB (candidata a modo "robusto") com alguns coisinhas integradas aqui acolá.

Por fim, as faculdades deveriam abolir os mantras, a menos que se esteja estudando naquela escola do Harry Potter.

SL não seria o que é se nã: SL não seria o que é se não fosse essa maravilhosa mania de reinventar a roda. :) E no mais, como eu poderia fazer as firulas integradas do Koffice usando o abiword e o gnumeric, hein hein hein?

Viva a firula!

webcam: está funcionando direitinho, tanto com o msn como com o yahoo, pena que ainda não tenha suporte a áudio

educação: "as faculdades deveriam abolir os mantras"

Elas deveriam abolir tudo o que é inútil, o que não é o caso aqui.

"Se não gosta, escolha o modo 'robusto'"

Que é mais "robusto" do que o do GNOME, no mau sentido. ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Hmmm... Então quer dizer qu: Hmmm... Então quer dizer que uma distro 100% Debian que é configurada para usar o repositório unstable deixa de ser Debian?!?!?!?!?!

128 MB: Eu estava usando no trabalho um Pentium III com 128MB e Fedora Core 3. Só o Xfce funcionava tranquilo, o Gnome era terrivelmente lento (não uso o KDE, então não sei nada sobre o desempenho deste). Quando consegui colocar 256MB de RAM as coisas melhoraram um pouco. Agora estou usando um Pentium 4 com 256 e finalmente tudo está rodando melhor.

Realmente 128MB de RAM não é fácil.

Michel Recondo
http://michel.recondo.nom.br/

E a distro?: Perdoem-me por este comentário, mas já levaram em consideração a distro em uso? Já instalei o Slackware 10.0 com KDE 3.2 num AMD K6-II 500 Mhz, c/ 96 MB RAM e a máquina rodou com uma performance razoável. Poxa, num Pentium III e com 128 MB ter um desempenho "terrívelmente lento", acredito ser isto no mínimo estranho...

Att., Ednei Pacheco,
Linux /home!

Para o caso acima do micro co: Para o caso acima do micro com 128, pelos testes que andei fazendo com Ubuntu, Kubuntu, Mandriva e Big Linux em máquinas com estas caracteristicas e até mesmo em máquinas mais antigas com processadores entre 400 e 700, o que ficou mais leve com Kde ou Gnome foi sem dúvida o Kurumin. Acredito que deva até ficar melhor que O Xp.

Realmente...: Realmente excelente. Eu sempre preciso acessar arquivos remotos via SSH, mas não conhecia mais essa funcionalidade do Konqueror. Valeu pela dica!

Não só no Konqueror, como e: Não só no Konqueror, como em qualquer aplicativo do KDE.
Dá pra editar um texto no Kate, por exemplo, usando o fish também.

"Que é mais "robusto" do que: "Que é mais "robusto" do que o do GNOME, no mau sentido. ;)"

A definição que v. mesmo deu não deixa dúvida, mais é melhor, sem poréns. :)

Não é simplesmente questão: Não é simplesmente questão de gosto, existem problemas técnicos que fazem integrar o Gtk+ a outros ambientes (usando Qt ou Windows para desenhar widgets, por exemplo) muito mais fácil que o contrário.

E tem muito mais!!: Além do fish, vc pode acessar máquinas windows sem o samba instalado (smb://servidorwindows), consultar páginas de manuais (man:comando) e até ler e-mails diretamente de um servidor pop.
Existem dezenas de outras funcionalidades. Para ver uma lista completa, abra uma janela do konqueror e digite "help:/kioslave/"

Divirtam-se :-)

Marcelo Vivan Borro

Mesmo se estivesse, isso não: Mesmo se estivesse, isso não acontece em nenhum sistema operacional que se preze. Softwares são carregados na memória à maneira que são utilizados.

less is better: vc nunca -- NUNCA, repito -- vai me ouvir falando que mais é melhor. A não ser de gozação...

Sou partidário da filosofia KISS: quanto menos banha, redundância, verbosidade, firulas e repetitividade no software, melhor...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Se vocês tivessem lido o e-m: Se vocês tivessem lido o e-mail do fundador do KDE explicando qual a proposta do KDE saberiam a resposta ao invés de falarem besteira =]

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org

Se o SL não reinventasse a r: Se o SL não reinventasse a roda hoje teríamos um concorrente à altura do Windows XP.

E dessa vez não foi meu! :): E dessa vez não foi meu! :)

Eu queria saber por que o pes: Eu queria saber por que o pessoal com Qtfobia e Kdefobia se incomoda tanto... já que não gosta do software por seus motivos basta não usar, é o bastante, mas ao invés disso preferem postar besteira... as vezes penso em responder com um texto de 500 linhas um post onde alguém falou uma merda muito grande mas logo depois desisto... afinal... pra que dar informação a quem não quer receber?

Reafirmando o que o colega acima disse... Agora é esperar pelos primeiros alphas do KDE4! ;-)

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org

As distros mais recentes vem: As distros mais recentes vem recheados de novos serviços para facilitar a configuração automatica e esses ambientes como KDE e GNOME também. Deveras tem pacotes que requerem versoes mais recentes do kernel como por exemplo o HAL e UDEV. Além disso, não é possivel sobreviver só com o KDE/GNOME, é preciso os aplicativos. O Gimp, OpenOffice e softwares do gênero requerem bastante memória.

E com o grito do pessoal implorando por mais facilidades não tem jeito, dai-lhe RAM!

O Xubuntu é bem fantastico no quesito memória, mas tem coisa podre, por exemplo, com 128M ele voa (talvez até 96M), mas estabiliza-se nessa performance e mesmo com 256M não noto nenhum ganho na performance. O GNOME com 256M roda lindo, com 512M roda melhor ainda, idem para o KDE.

Ednei, só o bluecurve do Fed: Ednei, só o bluecurve do Fedora já consome a maior parte da memória. Por isso o Slack é mais rápido.

Não seria só trocar o tema: Não seria só trocar o tema depois de instalado então ?
Ah sim, o tema padrão do Fedora agora é o Clearlooks que, se não me engano, vai ser o tema padrão do Gnome agora.

as vezes penso em responder c: as vezes penso em responder com um texto de 500 linhas um post onde alguém falou uma merda muito grande mas logo depois desisto... afinal... pra que dar informação a quem não quer receber?

Se voce nao contra-argumentar (nao estou falando de responder trolls), os voyers da lista podem dar ouvidos apenas às argumentações registradas e desconsiderar algo importante que voce saiba e outros não.

Por exemplo, um colega acima disse que ha uma razão para o KDE desenvolver os seus próprios produtos, mas não disse a razão. Eu sinceramente gostaria saber, enfim, alguns comentários são apenas socos para ar quando não são completos.

Concordo: Concordo, me considero como você falou, um "voyer" do site, dificilmente me manifesto, mas sempre leio todas as mensagens, fica mais fácil assim formar uma opinião.

Perfeito! Então o problema d: Perfeito! Então o problema de desempenho NÃO se deve ao ambiente gráfico utilizado. &;-D

Att., Ednei Pacheco,
Linux /home!

"vc nunca -- NUNCA, repito --: "vc nunca -- NUNCA, repito -- vai me ouvir falando que mais é melhor. A não ser de gozação..."

Ah! Então v. nunca dirá:

1) Um sistema MAIS robusto (o Gnome?) é MELHOR
2) Um sistema MAIS estável é MELHOR
3) Um sistema MAIS seguro é MELHOR

...
Olhando sob esse ângulo o Windows é mais KISS do que se pensa. :)

Ubuntu com KDE ou outro?: Fiz o download do ubuntu.
Agora, lendo as mensagens, fiquei com vontade de usar o KDE. Qual o melhor caminho: instalar KDE no Ubuntu ou pegar outra distribuição?
Tenho 512 de RAM, e quero criar um usuário para cada pessoa aqui de casa.

Que Mono/.NET que nada: Já estão até pensando em portar o GNOME para Eiffel. :D

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

vc pode esperar o KDE lançar: vc pode esperar o KDE lançar seu próprio kernel ( já começa com K! )

a partir daí, distribuições KDEx serão bem mais fáceis de encontrar...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Não funciona assim: Afinal, "reinventar" a roda é qualidade intrínseca do Software Livre, o que significa que é inextrincável dele. Não existiria software livre que não reinventasse a roda. Aliás, se você pensar bem, mesmo software proprietário funciona assim - a roda é reinventada a todo momento e por um motivo diferente: não para fazer algo levemente diferente (e supostamente melhor) como no caso do Software Livre, mas para não pagar o custo da licença da outra implementação proprietária...

Em minha opinião, esse excesso de alternativas que o software livre apresenta favorece, como já disseram aqui, uma espécie de "evolução" dos softwares.

Mesmo se a gente considerar isso, a alternativa a reinventar a roda seria reutilizar o que já existe; e reutilizar o que já existe também é uma característica muito, muito forte do Software Livre, mas aí tem aquele monte de gente que fala mal do evolution por ele usar mais de 50 bibliotecas diferentes... tsc. Tem gente que não se satisfaz nunca!

A propósito: eu posso concordar contigo com a sua frase, do seguinte modo:

"Se o SL não reinventasse a roda hoje teríamos um concorrente à altura do Windows XP."

O Software Livre já tem concorrentes bem melhores que Windows XP - no caso do Linux e *BDSs. Então, se não reinventássemos a roda, teríamos parado no tempo e só conseguiríamos ser tão bons quanto o XP...

Kubuntu: Existe uma variante do Ubuntu que utiliza o KDE como WM padrão - o Kubuntu. Experimente utilizá-lo. &;-D

Att., Ednei Pacheco,
Linux /home!

Olha...: Ironias à parte, uma distribuição do KDE seria realmente interessante

Não é o gnome... e sim o linux.: A política de gerenciamento de mem?ia utlizada no linux, diferente do windows (que é sob demanda), procura carregar a maior parte do sistema operacional na RAM. Então é natural que o gnome ou kde tentem carregar os aplicativos mais utilizados. Qqr dúvida, procurem ler sobre: "memória virtual" e "paginação".

Um pequeno exemplo: http://listas.cipsga.org.br/pipermail/linux-br/2005-August/010601.html


Guilherme Esmeraldo
-------------------
Esmeraldo.net

Gnome comilão.: Tenho um pentiun III c/196 de RAM,utilizando Debian-BR-CDD que já vem por padrão com o gnome,como eu gosto mais do KDE,baixei e instalei-o com o synaptic,mas mantive o gnome instalado,embora utilize somente o KDE.Testei o consumo de memoria de ambos,para carregar os ambientes, na mesma máquina,atraves do comando free.

Gnome 2.8 >>>
total used free shared buffers cached
Mem: 175716 173512 2204 0 12984 69016
-/+ buffers/cache: 91512 84204
Swap: 200772 22376 178396


KDE 3.3.2 >>>
total used free shared buffers cached
Mem: 175716 164812 10904 0 12616 85900
-/+ buffers/cache: 66296 109420
Swap: 200772 21636 179136

OU seja,vendo a quantidade de mémoria livre, o Gnome consumiu 25 megas a mais que o KDE,somente para carregar.

*Isto mesmo com o KDE carregando alguns aplicativos(Klipper,KOrganizer,KGpg),que utilizo, na inicialização.

Quando postei a formatação: Quando postei a formatação não se manteve,reduzi p/ver se fica mais claro...

Gnome 2.8 >>>
total free
Mem: 175716 2204
-/+ buffers/cache: 84204
Swap: 200772 178396


KDE 3.3.2 >>>
total free
Mem: 175716 10904
/+ buffers/cache: 109420
Swap: 200772 179136

Realmente, quis dizer Gnome.: Realmente, quis dizer Gnome. Corrige e compila de novo que vai rodar. hehehe
Haskell developer

E as versões atuais ?: Alguém fez este teste com o Gnome 2.12 e o KDE 3.5 ?
Pelo menos no Fedora e no Ubuntu, vi (na minha máquina) que o Gnome 2.12 está usando menos memória que o anterior e também senti uma leve melhora no desempenho (não tenho KDE para comparar entre eles).

smaps: O kernel 2.6.14 traz formas mais confiáveis (/proc/$PID/smaps) de aferir o uso real de memória por processos.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Windows também: Guilherme,

A mensagem acima dizia respeito ao fato do Gnome carregar bibliotecas (mesmo que não fossem utilizadas a princípio) na memória assim que o mesmo era inicializado. Isso é diferente de dizer que o sistema operacional utiliza parte da RAM (ou swap) para fazer cache com dados que ele acredite que vá precisa acessar com certa freqüência, o que tanto o Linux como o Windows fazem. Por sinal, a resposta correta para o caso desse link que você enviou tem mais a ver com o primeiro caso. A pessoa provavelmente estava utilizando o Oracle, que funciona exatamente dessa forma. Ele, Oracle, consome toda memória disponível logo após a inicialização para melhorar o seu desempenho. Se o sistema tiver 100 MB disponível, ele consome 100 MB. Se tiver 1 GB, ele vai consumir 1 GB.

E daí??: 1o. A pergunta inicial era: "Por que o Gnome sendo muito mais simples e minimalista que o KDE ainda consome tanta memória quanto ele?". Foram citados, também, "aplicativos/bibliotecas". A url que enviei, se você tivesse lido completamente, ententeria que fala a respeito de um cara querendo saber o "funcionamento" da memória no linux, que independe, claro, de gnome ou kde. Assim, para bons entendedores, responderia a pergunta.

2o. Memória Cache e Swap têm tudo a ver com a RAM. O linux carrega parte do sistema operacional, incluíndo "bibliotecas/aplicativos" na ram. Isso é fato. O cache recebe fatias dos apps mais utlizados e a swap vai receber parte dos menos utilizados("paginação" e "memória virtual", lembra?!? Assim, parte do kde e gnome são carregados na memória ram. A medida que vai-se utilizando os aplicativos, vai havendo trocas de informações(dados, programas em si, etc...) entre ram, cache e swap.

3o. Não vi, em lugar nenhum, alguém falando em inicialização e só bibliotecas. O que foi questionado é pq o gnome carrega tanta memória, o que foi respondido acima.

4o. Oracle ou qqr outro programa, em relação à memória, funcionam da mesma forma, quem faz o controle do uso da ram é o sistema operacional. Que software "escroto" é esse, que quebra as regras de gerenciamento de memória do SO???

5o. "Por sinal, a resposta correta para o caso desse link que você enviou tem mais a ver com o primeiro caso." -> Não entendi "bulhufas". Português, ou em qualquer linguagem, não é só juntar palavras e formar frases. Tem que haver sintaxa e semântica. Isso quer dizer que, o caso do link responde a pergunta sobre o gnome, que é o caso de estudo aqui debatido? Eu entendi isso. Então, você concordou comigo?



Guilherme Esmeraldo
-------------------
Esmeraldo.net

Esse pessoal gosta de um flame...:
Tem que haver sintaxa e semântica.

Se você não entendeu a frase, não teria sido mais fácil perguntar o real significado dela? Aliás, onde está o erro de "sintaxa" (sic) ou "semântica" na minha frase?

4o. Oracle ou qqr outro programa, em relação à memória, funcionam da mesma forma, quem faz o controle do uso da ram é o sistema operacional. Que software "escroto" é esse, que quebra as regras de gerenciamento de memória do SO???

E quem disse o contrário disso? Se você leu meu comentário, deve ter visto claramente que eu disse que se tratavam de coisas distintas. Vou tentar explicar de novo. Uma coisa é o gerenciamento de memória feito pelo SO. Quanto a isso, a única coisa que eu disse é que o Windows também se comportava da mesma maneira que o Linux, ao contrário do que você disse. Outra coisa completamente diferente é o que um programa carrega em memória durante a sua incialização e utilização. Onde é que você me viu dizer que o Oracle quebrava as regras de gerenciamento de memória nessa explicação ou naquela do primeiro comentário?

A url que enviei, se você tivesse lido completamente, ententeria que fala a respeito de um cara querendo saber o "funcionamento" da memória no linux

A dúvida presente no link do fórum cipsga que você enviou dizia respeito ao uso excessivo de memória por parte de um BD. A explicação citada no próprio fórum relacionava isso ao gerenciamento de memória. E eu disse que isso não era verdade. A causa desse uso excessivo era que o Oracle utiliza toda memória livre quando da sua utilização para carregar o que ele considera importante para melhorar seu desempenho. A explicação que a pessoa dava no fórum sobre gerenciamento estava correta, mas não era essa a resposta correta para a pergunta feita. Volto a dizer: a reposta para aquela pergunta do fórum da cipsga não tem nada a ver com gerenciamento de memória! Deu pra entender?

Quanto ao restante do seu comentário, não se preocupe, eu também estudei pelo Tanenbaum nas cadeiras de Sistemas Operacionais e Arquitetura de Computadores na faculdade :)

Humpf: O que eu "acho" é que o Gnome "deve" carregar as bilbiotecas/aplicativos("mais utilizados ou do core") como a GTK/Gnome/Gconf2 e outras e mantêlas na memória mesmo que o aplicativo que as chamou esteja fechado.
Desta forma ele precisa de memória RAM para se manter rápido. E desta forma se tiver memória abrirá mais rápido os aplicativos.
Mas, também deve se considerar "outras possibilidades", mesmo assim esta me parece mais lógica/racional mesmo não tendo comprovação(fato que qualifica como possível).

_______________________________________________________________

"Só sei que nada sei" Sócrates

"O Homem está condenado a ser livre" Jean Paul Sartre

Os banco de dados, ou se pref: Os banco de dados, ou se preferir gerenciadores de banco de dados como Oracle, Sybase e MSSQL tem como parametro de tunning reservar uma quantidade especifica de memória, e em alguns casos o RDBMS entra por padrao reservando quase toda a memória livre do sistema (nao sei como ele calcula isso).

Por que ? Porque se ele reservar uma quantidade de memória suficiente, esta quantidade de RAM será contigua e o gerenciador/sistema operacional nao perde tempo alocando/desalocando memória. Isso é personalizado dentro do aplicativo. O FirebirdSQL tem um comportamento diferente ele aloca memória a medida que vão sendo requisitados, porém não as libera novamente, entao se o firebirdsql atingir um pico de 512M será sempre 512M até o próximo reboot.

Esse comportamente está correto para mim. Claro que há aqueles que tiveram contato superficial com o banco de dados e que vao achar isso desnecessário, assim como o fato dum banco de dados robusto ter que ser dedicado. Mas o fato é que cada RDBMS tem seu próprio comportamento e é preciso entender porque ele se comporta assim ou assado.

Então não está errado o que o colega acima falou a respeito do Oracle, esse procedimento é esperado e quem compra um RDBMS tem que conhecer o que se está instalando, servidor compartilhado ou dedicado? Quais os requisitos minimos ? Qual é o comportamento esperado dele com locks ? Ou porque é assim ou assado, etc...