Primi test comparativi tra KDE 4 ed il predecessore

[Clauser]

Originariamente inviato da Cimmo

ah ah ah!
PS: Sotto KDE4 e' pure possibile vedere la ram occupata in totale e al netto del caching, fantastico, Vista invece non fa distinzione...

Penso che quello lo puoi vedere da una decina d'anni e forse di più

iceman@fulgore ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          1004        514        489          0         44        151
-/+ buffers/cache:        319        684
Swap:          494          0        494

[afsdfdlecosdfsfdcco]

Originariamente inviato da Clauser

Università degli studi di Verona. Solo ed esclusivamente linux.

Nei laboratori c'e' linux (ubuntu livenet univr edition) ma le segretarie mi pare usino xp

[Cimmo]

Originariamente inviato da Clauser

Penso che quello lo puoi vedere da una decina d'anni e forse di più

va bene infatti parlo di KDE, cioe' un modo visuale, per utonti.
Dai su cerchiamo di capirci

[ilsensine]

Originariamente inviato da WarDuck

Fatemi capire, ci si rifersce al solo KDE oppure, come sembrerebbe, anche agli altri programmi e servizi (o demoni che dir si voglia) che girano sotto?

Da quello che leggo, sono conteggiate solo le applicazioni lanciate da kde

Cmq vi ricordo che c'è chi afferma che xp ottimizzato gira in 90mb di memoria.

Attualmente io sto consumando sotto xp 237mb di memoria con firefox, messanger e diversi altri programmi

Periodicamente capita nella sez. linux qualche nuovo utente che chiede "ma come, ho appena lanciato linux e già mi occupa l'70% della memoria?". La mia risposta tipica è "sì c'è qualcosa che non va, stai sprecando il 30% della tua memoria". O qualcosa del genere.
Il fatto che Vista abbia la fama di essere più "vorace" di memoria non vorrei che sia lo stesso: gestisce la memoria meglio di XP. Se poi attivi Aero e tutti i fronzoli, certo che occupa più memoria. Ci mancherebbe!

[Lck84]

Originariamente inviato da Clauser

Invece no, su linux il sistema delle dipendenze fa si che venga caricata un'unica libreria (quella più aggiornata). Su osx vengono caricate entrambe le librerie, anche se sono della stessa versione. L'altra faccia della medaglia dei pacchetti preconfezionati. Non è sicuramente il massimo dell'ottimizzazione.

Sì eh? E se la libreria più aggiornata non è retrocompatibile, l'applicazione compilata per la libreria vecchia va in crash. Bellissimo.
Non so Gtk, ma in wxWidgets ci sono diversi metodi dichiarati obsoleti e rimossi dalle versioni "vecchie". Di fatto, se si usa un applicazione "vecchia" bisogna avere due versioni di wxWidgets oppure ricompilare l'applicazione perché supporti la nuova versione (modificandone il codice).
E ovviamente la prima soluzione, che è la più semplice, è una faticata mostruosa proprio grazie al sistema delle dipendenze. È una buona soluzione al "Dll Hell", ma suppone che tutte le applicazioni siano sempre aggiornate e tengano traccia dell'evoluzione del sistema, il che è una buona cosa, ma non sempre possibile.

Originariamente inviato da Cimmo

Parlo sempre al netto del caching, quindi non mi venite a menare con sta storia del caching!
PS: Sotto KDE4 e' pure possibile vedere la ram occupata in totale e al netto del caching, fantastico, Vista invece non fa distinzione...

Ma per piacere, come al solito ci sono i troll che non hanno mai messo piede su Linux (o l'hanno fatto per 10 minuti con una live) e parlano per sentito dire.

Come dice diabolik, magari se anche tu "mettessi piede" in Vista prima di dire cose non veritiere...

Appena 1 mega di Ram non sfruttato.

Originariamente inviato da ilsensine

Il fatto che Vista abbia la fama di essere più "vorace" di memoria non vorrei che sia lo stesso: gestisce la memoria meglio di XP. Se poi attivi Aero e tutti i fronzoli, certo che occupa più memoria. Ci mancherebbe!

Esatto.

Ma per tornare all'articolo, sbaglio o KDE 4 usa più memoria di KDE 3? Ci sono un sacco di grafici e il testo è in polacco purtroppo...

Originariamente inviato da Lck84

Sì eh? E se la libreria più aggiornata non è retrocompatibile, l'applicazione compilata per la libreria vecchia va in crash. Bellissimo.
Non so Gtk, ma in wxWidgets ci sono diversi metodi dichiarati obsoleti e rimossi dalle versioni "vecchie". Di fatto, se si usa un applicazione "vecchia" bisogna avere due versioni di wxWidgets oppure ricompilare l'applicazione perché supporti la nuova versione (modificandone il codice).
E ovviamente la prima soluzione, che è la più semplice, è una faticata mostruosa proprio grazie al sistema delle dipendenze. È una buona soluzione al "Dll Hell", ma suppone che tutte le applicazioni siano sempre aggiornate e tengano traccia dell'evoluzione del sistema, il che è una buona cosa, ma non sempre possibile.

Già, molto più saggio fermare il progresso perchè lo sviluppatore di un ipotetico programma non aggiorna il proprio software da migliaia di anni (solitamente il metodo dell'ipotetica libreria viene prima dichiarato obsoleto/deprecato e dopo un po' di versioni, al limite, viene rimosso... questo proprio per lasciare il tempo di migrare il software).

Comunque esistono anche package manager in grado di gestire più versioni del software contemporaneamente.

[Clauser]

Originariamente inviato da Lck84

Sì eh? E se la libreria più aggiornata non è retrocompatibile, l'applicazione compilata per la libreria vecchia va in crash. Bellissimo.
Non so Gtk, ma in wxWidgets ci sono diversi metodi dichiarati obsoleti e rimossi dalle versioni "vecchie". Di fatto, se si usa un applicazione "vecchia" bisogna avere due versioni di wxWidgets oppure ricompilare l'applicazione perché supporti la nuova versione (modificandone il codice).

Semplice se la libreria aggiornata non è retrocompatibile succede questo:
A)Ti aggiorni il programma alla versione nuova (kde è tutto fatto così, quando esce una nuova versione, tutti i programmi in qt vengono aggiornati di conseguenza)
B)Il sitema di gestione dei pacchetti ti avverte del problema e allora decidi tu se continuare l'installazione della nuova libreria e disintallare il programma in questione o aspettare un aggiornamento del programma che supporti tale libreria.

[RunAway]

Originariamente inviato da Clauser

Invece no, su linux il sistema delle dipendenze fa si che venga caricata un'unica libreria (quella più aggiornata). Su osx vengono caricate entrambe le librerie, anche se sono della stessa versione. L'altra faccia della medaglia dei pacchetti preconfezionati. Non è sicuramente il massimo dell'ottimizzazione.

Non è che siano poi rarissimi i pacchetti che non usano le librerie standard del mac (cocoa?). Vedi amule e buona parte dei programmi opensource.

Veramente non hai afferrato che in os x non c'è una giungla di librerie e desktop manager come in linux.
Guarda che in os x dentro i .app non c'è mica una copia della libreria che serve, al massimo ci trovi un framework molto specifico per quell'app.
aMule funziona con le wxwidgets, ma non tocca all'utente procurarsele.
In Tiger che ha le wx 2.6 se non erro usavo amule compilato con le wx 2.8 ma mica dentro amule ha una copia di tutte le wx.

E cmq su os x c'è molto software free, open e nativo per cui capita raramente che ci si debba ingarbugliare con x11 e tutto ciò che concerne.

[Lck84]

Originariamente inviato da ekerazha

Già, molto più saggio fermare il progresso perchè lo sviluppatore di un ipotetico programma non aggiorna il proprio software da migliaia di anni (solitamente il metodo dell'ipotetica libreria viene prima dichiarato obsoleto/deprecato e dopo un po' di versioni, al limite, viene rimosso... questo proprio per lasciare il tempo di migrare il software).

Mai detto questo. Semplicemente si faceva una questione di "scarsa ottimizzazione" nel caso della coesistenza di librerie di più versioni, mentre il problema è semplicemente di compatibilità.
So benissimo qual è l'iter di deprecazione/obsolescenza, ma questo non significa niente. Se un programma è compilato per wxWidgets 1.0 ed io ho la 2.5.7, è piuttosto probabile che non funzioni. Nel caso migliore devo comunque mettere le mani nel codice del programma per renderlo compatibile con la nuova libreria, mentre avere semplicemente la libreria vecchia installata è più semplice (per lo sviluppatore e per l'utente).

Originariamente inviato da Clauser

Semplice se la libreria aggiornata non è retrocompatibile succede questo:
A)Ti aggiorni il programma alla versione nuova (kde è tutto fatto così, quando esce una nuova versione, tutti i programmi in qt vengono aggiornati di conseguenza)
B)Il sitema di gestione dei pacchetti ti avverte del problema e allora decidi tu se continuare l'installazione della nuova libreria e disintallare il programma in questione o aspettare un aggiornamento del programma che supporti tale libreria.

Sì, ma il problema sussiste, perché così com'è non riuscirò ad eseguire il programma se non ricompilandolo/modificandolo a mano.

Non fraintendete: io apprezzo il gestore di pacchetti e l'aggiornamento tramite repository. Lo trovo estremamente comodo. Però non è il "silver bullet" per la gestione del software, perché appena dobbiamo confrontarci con software che esula dal pacchetto "comune" (che viene aggiornato periodicamente e/o ha un autore attivo) ci sono problemi. Ne sono arcisicuro perché proprio ora devo gestire un progetto che dipende dal tool statistico R e c'è stato un "breaking change" nell'interfaccia (piccolo, ma fondamentale) dalla versione 2.5 in poi e mi trovo costretto a tenere una versione del software compilato a mano con tutte le dipendenze "vecchie" ugualmente compilate a mano (e non è divertente né facile).
edit: tra l'altro, devo fare la stessa cosa sia per Linux che per Windows, quindi il risultato non cambia. L'unica differenza è che con Windows riesco a fare un pacchetto e scriverci "funziona con R 2.5 che trovi su internet", mentre su Linux devo scriverci "scarica R 2.5, compilalo e setta tutti i riferimenti". È solo una questione di comodità per l'utente finale.

[Clauser]

Originariamente inviato da RunAway

Veramente non hai afferrato che in os x non c'è una giungla di librerie e desktop manager come in linux.
Guarda che in os x dentro i .app non c'è mica una copia della libreria che serve, al massimo ci trovi un framework molto specifico per quell'app.
aMule funziona con le wxwidgets, ma non tocca all'utente procurarsele.
In Tiger che ha le wx 2.6 se non erro usavo amule compilato con le wx 2.8 ma mica dentro amule ha una copia di tutte le wx.

Esempio: creo un programma in python che richiede la libreria pippov1.0.py. Quella libreria va inclusa nel pkg
Tu crei un altro programma sempre scritto in python che richiede la libreria pippov1.1.py, anche tu la metti ovviamente nel pkg.
Lanci entrambi i programmi, in ram quanti pippo hai? Uno o due?

[Clauser]

Originariamente inviato da Lck84

Non fraintendete: io apprezzo il gestore di pacchetti e l'aggiornamento tramite repository. Lo trovo estremamente comodo. Però non è il "silver bullet" per la gestione del software, perché appena dobbiamo confrontarci con software che esula dal pacchetto "comune" (che viene aggiornato periodicamente e/o ha un autore attivo) ci sono problemi. Ne sono arcisicuro perché proprio ora devo gestire un progetto che dipende dal tool statistico R e c'è stato un "breaking change" nell'interfaccia (piccolo, ma fondamentale) dalla versione 2.5 in poi e mi trovo costretto a tenere una versione del software compilato a mano con tutte le dipendenze "vecchie" ugualmente compilate a mano (e non è divertente né facile).

Per questi (rari) casi puoi usare un packet manager come portage che volendo gestice più versioni della stessa libreria. Certo, è uno schifo a livello di ottimizzazione, ma piuttosto che prendersi la briga di modificare il codice di un programma bello che morto..

[^TiGeRShArK^]

Originariamente inviato da trashofmasters

Dal mio punto di vista l'os che ha lacune è windows, ce ne vorrà ancora finchè windows riesca a raggiungere l'efficenza di un sistema unix like.
A mio modesto parere windows è qualcosa di sbagliato già in partenza, cioè per un utente avanzato questo conta, per l'utente che controlla le mail non fa alcuna differenza, quindi non mi aspetto di essere compreso da tutti

ovvero?
definiscimi un utente avanzato.
Io credo di esserlo dopo circa 16 che uso il pc..
eppure con linux spreco molto + tempo per configurare il tutto o per risolvere incompatibilità o per mille cose che, a quanto sembra, accadono solo a me.
Con windows non ho mai avuto problemi di sorta.
Eclipse funziona subito e senza alcun problema.
Quando abbiamo dovuto fare l'ambiente di sviluppo per Diamonds c'era Cesare che ha bestemmiato non so quanto tempo per fare andare il tutto su linux, chiedendo anche qui sul forum.
Per me un sistema operativo che mi fa perdere tempo non è produttivo dato che piuttosto che perdere tempo per cavolate preferisco impiegare il mio tempo per fare effettivamente quello per cui mi pagano.

[^TiGeRShArK^]

Originariamente inviato da manu@2986

Beh io uso arch...e dato che non è una delle distribuzioni più diffuse in teoria dovrei aver problemi a trovare pacchetti...invece no...c'è tutto nei repository...

si vabbè..quindi in pratica dovrei usare una distro diversa per le diverse cose che dovrei fare?
e quindi tornaimo al punto di prima..
qual'è l'utilità di avere n distro diverse se poi NESSUNA di esse è davvero completa, ma ci sono sempre cose che le altre distro non hanno?

[Ilbaama]

Secondo me è meglio avere una copia delle librerie, nel caso fossero incompatibili, per due programmi piuttosto che non doverne usare uno per risparmiare un po' di RAM. Di sicuro non è il massimo per l'ottimizzaione, ma sempre meglio di rimanere senza l'utilizzo di un programma.....e poi non è che le librerie siano di centinaia di mega, a volte sono solo pochi KB.

[RunAway]

Originariamente inviato da Clauser

Esempio: creo un programma in python che richiede la libreria pippov1.0.py. Quella libreria va inclusa nel pkg
Tu crei un altro programma sempre scritto in python che richiede la libreria pippov1.1.py, anche tu la metti ovviamente nel pkg.
Lanci entrambi i programmi, in ram quanti pippo hai? Uno o due?

E no in questo caso sbagli già in partenza perchè sta a te usare l'ultima versione della libreria.
Cmq in questi casi viene utilizzato il metodo di installazione a pacchetto col setup avanti avanti ed è molto probabile che quella particolare libreria venga implementata come framework e vada a finire in un posto comune la prima volta che installi quel programma.
Altri programmi dipendenti da quella libreria molto probabilmente saranno sempre con installazione a pacchetto e installeranno il necessario. Ma se quella libreria esiste già le due app la condivideranno.
Po certo ci sono i casi in un programmatore fa le porcate e capita anceh il caso da te descritto ma è colpa di chi fa le app non del sistema.

Cmq questo è quello che apre aMule.app (adunanza)
http://rafb.net/p/bVhLRk90.html

Come vedi è tutta roba di sistema praticamente.

Originariamente inviato da Lck84

Mai detto questo. Semplicemente si faceva una questione di "scarsa ottimizzazione" nel caso della coesistenza di librerie di più versioni, mentre il problema è semplicemente di compatibilità.

Vero, ma è un approccio al problema della retrocompatibilità che porta ad una scarsa ottimizzazione.

So benissimo qual è l'iter di deprecazione/obsolescenza, ma questo non significa niente. Se un programma è compilato per wxWidgets 1.0 ed io ho la 2.5.7, è piuttosto probabile che non funzioni. Nel caso migliore devo comunque mettere le mani nel codice del programma per renderlo compatibile con la nuova libreria, mentre avere semplicemente la libreria vecchia installata è più semplice (per lo sviluppatore e per l'utente).

Il problema della "compilazione" è molto relativo, la stragrande maggioranza del software utilizzato su Linux viene distribuito sotto forma di codice sorgente da compilare e non come binario precompilato (fatta eccezione dei vari programmi closed-source o comunque in cui non è fornito il codice sorgente), quindi ognuno lo compila come vuole.

Al limite possiamo trovare binari precompilati nei pacchetti precompilati di alcune distribuzioni, in quel caso i maintainer delle varie distribuzioni si fanno carico di fare in modo che i software distribuiti funzionino correttamente con la libreria distribuita.

Concludendo... se un ipotetico programma utilizza le wxWidgets 1.0 (con metodi obsoleti, deprecati, rimossi), è ora che il suo sviluppatore lo aggiorni.

[^TiGeRShArK^]

Originariamente inviato da Clauser

Penso che quello lo puoi vedere da una decina d'anni e forse di più

iceman@fulgore ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          1004        514        489          0         44        151
-/+ buffers/cache:        319        684
Swap:          494          0        494

..dai tempi del windows 2000...
anzi..
se proprio vogliamo fare i pignoli anche dal dos 5.0 in poi
bastava guardare a quanto era settato il valore di memoria di SMARTDRV

EDIT: mmm.. anzi forse ora che ci penso mi pare che SMARTDRV venne introdotto addiritturra col DOS 4..
ma potrei anche sbagliare visto che sono passati giusto un pò di annetti

[Clauser]

Originariamente inviato da RunAway

E no in questo caso sbagli già in partenza perchè sta a te usare l'ultima versione della libreria.

E se l'ultima versione è uscita due ore dopo il rilascio del mio programma?
A parte che sono abbastanza sicuro che mac carichi in ram due volte la stessa libreria anche se è della stessa versione (in caso di librerie nei pacchetti.app, non di sistema, ovviamente)

Cmq in questi casi viene utilizzato il metodo di installazione a pacchetto col setup avanti avanti ed è molto probabile che quella particolare libreria venga implementata come framework e vada a finire in un posto comune la prima volta che installi quel programma.

Qua si parlava della presunta superiorità del drag 'n drop. Percarità, comodissimo, ma se anche potessi averlo non lo installerei mai proprio per il problema dell'esempio. Sono uno che guarda l'ottimizzazione e lo spreco di risorse prima di tutto il resto (mica per niente uso gentoo e uso pacchetti con le stesse librerie grafiche )

[RunAway]

Originariamente inviato da Clauser

E se l'ultima versione è uscita due ore dopo il rilascio del mio programma?
A parte che sono abbastanza sicuro che mac carichi in ram due volte la stessa libreria anche se è della stessa versione (in caso di librerie nei pacchetti.app, non di sistema, ovviamente)


Qua si parlava della presunta superiorità del drag 'n drop. Percarità, comodissimo, ma se anche potessi averlo non lo installerei mai proprio per il problema dell'esempio. Sono uno che guarda l'ottimizzazione e lo spreco di risorse prima di tutto il resto (mica per niente uso gentoo e uso pacchetti con le stesse librerie grafiche )

Il drag'n'drop è superiore non ci sono storie, installi mettendo dove vuoi e disinstalli buttando nel cestino è il sistema + semplice ceh si possa concepire.
E tutta questa inefficenza e spreco di risorse proprio non esiste e anzi os x essendo ottimizzato per l'hardware e viceversa va molto veloce.

[floc]

Originariamente inviato da ^TiGeRShArK^

Io credo di esserlo dopo circa 16 che uso il pc..
eppure con linux spreco molto + tempo per configurare il tutto o per risolvere incompatibilità o per mille cose che, a quanto sembra, accadono solo a me.

evidentemente credi male... chiediti perche' capitano solo a te certe cose. Se non si sa usare linux non diamo la colpa al SO per partito preso. Certo che se uno che infila il cd di ubuntu e preme avanti avanti avanti si sente un accher perche' ha installato linux siamo apposto.

In ogni caso, la ram c'e', la paghiamo, usiamola! Il problema e' quando i programmi non la liberano se serve! Pertanto, detta terra terra, me ne batto se "xp ottimizzato occupa 90 mega di ram" se poi appena apri qsa ne applica 400 e non la libera piu' manco a morire... E' anche l'efficienza dello scheduler del SO l'importante, non solo quanta ram occupa all'avvio. Io (evidentemente folle) all'avvio della macchina ho uno script che carica in ram piu' di 500 mega di roba per essere piu' veloce... Pazzo eh?