Eu acho que uma boa definição é provavelmente como "Se eu tentar usá-lo em uma máquina antiga, ele funcionará perfeitamente".
Mesmo que, digamos, uma máquina Pentium II seja hoje tão antiga que algumas pessoas simplesmente "vão embora" em vez de se concentrar na leveza, o problema é: há gerenciadores de janela (e talvez simples DEs, como o XFCE antes de começar a ficar mais inchado), o que funcionará bem na dita máquina. Eles são leves.O Firefox, OTOH, tem vazamentos de memória e requer várias centenas de megabytes para manter várias guias abertas. Ele parou de ser leve em algum lugar antes do Firefox 2 ter sido lançado.
Seu "não consome muitos recursos do computador" também é outro possível ponto de referência. Com esse antigo benchmark da máquina, a memória geralmente é o maior problema: programas como o LibreOffice, mesmo que não sejam lentos, exigem mais memória do que digamos, seu editor de texto comum do UNIX (quero dizer, coisas comoEmacs , vi , nano ou borboletas).
Mesmo assim, o uso da CPU ou o acesso ao disco pode ser outra coisa a considerar. Eu não gosto do novo seletor de arquivos GTK não apenas por causa do redesenho da interface do usuário , mas também porque Quando eu usei uma máquina mais antiga, notei que uma das mudanças que eles fizeram foi introduzir o sniffing de arquivo que você simplesmente não podia desligar. Isso introduzia longos atrasos toda vez que algum aplicativo GTK + abria um seletor de arquivos, especialmente em diretórios com vários arquivos. Fazer ls ou usar o seletor de arquivos QT seria rápido e fácil. O Firefox também teria seu próprio seletor de arquivos. Mas, digamos, o Firefox com o seletor de arquivos GTK +, solicitando que o binário abra um arquivo, abriria / usr / bin e levaria vários segundos para ser processado. Desde então, acho que podemos dizer que o selecionador de arquivos GTK + não é leve. Um kit de ferramentas leve talvez permita que você desative esse sniffing, pois pode ser intensivo.
"o aplicativo não bifurca novos processos", "(um processo único ou somente threads)": não sei quanto, mas os processos provavelmente serão mais lentos que os threads, sim. Considerar a segmentação / vários processos (mesmo que o último seja mais lento que o antigo) é uma boa ideia - a menos que estejamos falando de um programa que bifurque muito (por exemplo, bom e velho bash garfo), eles não usarão muitos recursos, enquanto eles podem melhorar a capacidade de resposta. Uma coisa que pode até mesmo acontecer é que alguém que considera um programa leve se for responsivo dirá que um programa não é leve se bloquear por alguns segundos fazendo algo que está sob o capô, e uma forma de evitar isso é ter tópicos, um lidando com a interface do usuário e o outro fazendo essas coisas sob o capô.
O peso leve também pode ser "apenas com os recursos necessários". Por exemplo, como não sou muito de um mouse ou de uma pessoa gráfica, prefiro players de mídia que podem ser iniciados com um arquivo e apenas mostram o arquivo com atalhos de teclado, em vez de um GUI com muitos botões e controles para usar com o rato. Eu poderia dizer que mplayer é leve em comparação com suas versões da GUI (ou, digamos, vlc , embora eu ache que haja cvlc ). No final, mesmo que isso não exija muita memória ou recursos da CPU, ela ainda pode ser considerada "leve" se você pensar nela como "economia de espaço na tela".
Muitos gerenciadores de janelas podem ser considerados leves em comparação com ambientes de desktop porque os DEs fornecem vários aplicativos e ferramentas para fazer várias coisas, enquanto os WMs apenas gerenciam janelas (os DEs têm, de fato, WMs como um de seus componentes ).
Uma pequena ferramenta de linha de comando que executa algumas tarefas também é leve se comparada a alguns aplicativos GUI, oferecendo vários menus para fazer a mesma coisa, especialmente se você tiver que percorrer os menus e opções para fazer algo rápido com um comando. (Embora aqui eu possa ser tendencioso, como acontece com minha máquina antiga, essas ferramentas GUI normalmente seriam mais lentas, apenas por causa da GUI.)