Newsgroup: it.comp.os.dibattiti
Titolo: Re: com'erano belli i s.o. monotask e senza librerie a collegamento dinamico

 in giro a rallentare il computer.
Sei completamente ubriaco o stai trollando? 
Multitasking e collegamento dinamico *non* creano problemi con quello
che dici. Tanto e' vero che copiare i programmi come dici e' la pratica
tipica su OS X, che ha multitasking *e* collegamento dinamico. Anche la
cancellazione funziona come hai descritto.
Forse non ti e' chiaro cosa sia il collegamento dinamico.
Suppongo anche che tu non abbia ma usato il DOS o ti sia scordato dei
tanti piccoli e meno piccoli problemi demenziali che aveva. Guarda,
scrivo solo una parola: TSR.
-- 
-riko


Me ne viene in mente uno....

 non vengono copiate.
Fattelo sfuggire: questo *accade*. E' il metodo *tipico* e *standard* di
operare sotto OS X. 
Il metodo e' semplice *non* metti la DLL nella directory di sistema ma
te la porti nella stessa directory dell'eseguibile (o in un path
relativo all'eseguibile). Se hai la semantica ricca dei bundles, lo fai
anche in modo trasparente. 
Se non hai questa semantica semplicemente copi la directory del
programma, dove magari tieni anche files di help e compagnia. Questo
puo' avvenire anche sotto windows, sebbene non sia comune.
Alcuni software proprietari e non sotto Linux che hanno una
distribuzione diversa dal pacchettizzatore di sistema spesso usano
proprio questo sistema. Ovviamente nel mondo dei pacchettizzatori questo
e' meno comodo e si preferisce questa strada.
-- 
-riko


:-)

 E poi la stabilit�; vi si � mai bloccato un programma sotto dos?
Un fottio di volte!!
-- 
Sensei�<Sensei's e-mail is at Me-dot-com>
If you get this in less than 10 seconds, then you are a certified geek.
"FEATUR"
(License plate seen on an old Volkswagen Beetle)

 non vengono copiate.
Trascinandone l'icona in OSX, ad esempio. Molti programmi usano 
librerie dinamiche, e la DLL hell non e` propria di tutti gli OS.


 Me ne viene in mente uno....
il GEOS?
Ciao Jack

 quale?
PippaOS! :D
-- 
Sensei�<Sensei's e-mail is at Me-dot-com>
Three things are certain
Death, taxes, and lost data
Guess which has occurred. (Computer's Haiku)


Ora non ti ci mettere pure tu....

 disinstallare, ma in giro per l'hard disk ci sar� ridondanza di codice.
Di fatto non sono tanti i programmi che usano le stesse librerie. O
meglio, le librerie ampiamente utilizzate sono sufficientemente note da
essere distribuite con l'OS.
La ridondanza su hard disk esiste. E' inevitabile e poco costosa. Quanto
prende una libreria? 2 MB a dir tanto. Quanti GB abbiamo?
Rimane la condivisione in RAM, la facilita' di aggiornamento,
eventualmente ci possono essere meccanismi che prendono la piu' recente
libreria dinamica disponibile nel sistema e compatibile con
l'applicazione.
-- 
-riko

 una volta l'anno a dire tanto.
A me una volta alla settimana come minimo. Evidentemente usavamo 
programmi diversi.
p.bes

 directory.
Si. Ne` IBM-DOS ne` MS-DOS avevano di default A:\>.
-- 
Sensei�<Sensei's e-mail is at Me-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 Ora non ti ci mettere pure tu....
Non te la prendere, e` che pippaos e` stata una luce nel tunnel della 
nerdizzazione! :)
-- 
Sensei�<Sensei's e-mail is at Me-dot-com>
Research (n.): a discovery already published by a chinese guy one month
� � � � � � �� before you, copying a russian who did it in the 60s.

 nerdizzazione! :)
Sei sicuro? Chiedi ad Anna.

  
non sono d'accordo.
� vero, se macosX usa questo metodo ha la comodit� di poter spostare le 
applicazioni da un sistema all'altro, poterle cancellare togliendo la 
directory, ecc.
ma chi ha pensato di mettere le librerie condivise in una directory 
condivisa non era deficiente.
se ogni programma installa una sua versione della libreria nella sua 
directory:
1) perdi la condivisione in ram della libreria visto che sar� quasi 
sempre diversa come versione per ogni software. Inoltre dubito (non ho 
voglia di andare a cercare in merito) che un qualsiasi s.o. possa 
accorgersi che due librerie sono identiche applicando il text sharing se 
sono collocate in directory diverse: ad es. il file potrebbe chiamarsi 
allo stesso modo e riportare la stessa versione ma essere compilato in 
modo diverso, inibendo la possibilit� di condividerne il codice.
2) perdi la possibilit� di aggiornare una volta sola la libreria per 
tutti i software, dovendo aggiornare ogni copia della libreria in 
diverse directory
3) perdi la possibilit� di poter configurare una volta sola e 
globalmente la libreria e ti ritrovi di solito con una diversa 
configurazione della libreria per ogni directory in cui � copiata
Non a caso, GTK anche su win pu� mettersi nei "File comuni", purtroppo 
per� molte applicazioni se ne portano dietro una loro versione generando 
pi� casini che vantaggi, oltre a buttare nel ce$$o un tot di MB RAM e 
rallentare anche l'avvio dei programmi.
Io su win in questo momento ho:
- thunderbird con le sue gtk, xul e gecko
- firefox con le sue gtk, xul e gecko
- openoffice con le sue gtk
- pidgin che usa le gtk condivise nei file comuni (credo)
Cio� ho 4 diverse versioni di GTK, 2 di xul e 2 di gecko caricate, che 
fanno tutte la stessa cosa. Bella merda. E magari ne ho pure altri che 
non voglia di verificare.. Google Desktop? Cobian Backup? AVG?..
Su linux � tutto condiviso e infatti a parit� di applicazioni aperte ho 
mediamente circa META' RAM usata rispetto a windows.
MacOsX pu� avere n copie delle librerie per comodit�, ma non � 
assolutamente il metodo pi� efficiente.

 manica di idioti.
Quando avrebbe detto che sono degli idioti, scusa?
A livello di consumo RAM ha detto una verità inconfutabile: è meno 
efficiente.
-- 
Vide

 
I PBI in PC-BSD sono fatti per contenere tutte le librerie in modo non 
condiviso.
Trovi una lunga discussione sui PBI qui:
http://www.osnews.com/comments/21293
Scoprirai che per evitare le librerie condivise, oltre ai problemi che 
avevo elencato prima, ti ritrovi:
- gravi problemi di sicurezza quando vengono fixati i bug in una 
libreria: invece che aggiornarla una volta system-wide, i packager 
devono aggiornare TUTTI i pacchetti che la usano e ridistribuirli 
tutti... ovviamente � sottinteso che se il packager non � pi� 
disponibile a fare il lavoro per il programma X, la gente continua ad 
usarlo con una versione bucata della libreria.
- package di installazione GIGANTESCHI perch� ogni programma si porta 
dietro 1000 file di librerie, quindi oltre al problema RAM e hard disk 
hai anche quello di aspettare che l'ADSL scarichi tutto..
Ad esempio PIDGIN:
* Mandriva Linux RPM: 2,59 MB + le librerie se mancano sul tuo sistema 
(
http://rpm.pbone.net/index.php3/stat/4/idpl/12799958/com/pidgin-2.5.9-1.2mdv2009.1.i586.rpm.html
)
* PC-BSD PBI: 43,55 MB (
http://www.pbidir.com/bt/pbi/1/pidgin
)
* Windows SETUP.EXE: 7 MB senza GTK, 14 MB con le GTK
* MacOSX: sconosciuto, ti rimanda al download via  Fink.
Il confronto � vergognoso.
Ma cosa ci vuoi fare, oggi non frega pi� niente a nessuno 
dell'ottimizzazione e della sicurezza dei sw, basta che siano semplici 
da usare.

 efficiente.
Che poi comunque il pacchetto SW sarà anche tutto nello stesso bundle ma poi 
la merda a livello utente un qualunque software di OSX te la lascia come un 
qualunque altro software in un qualunque altro sistema operativo.
Anzi, devo dire che spannometricamente il mio Tiger col passare del tempo e 
dei programmi messi e tolti va sempre un po' più lento (il mio utente 
principale, ovviamente). Non siamo ai livelli di Windows ma la strada è 
quella. 
-- 
Vide

 quella. 
Dovresti provare a dimostrare che avere un file *inerte* sull'hard disk
rallenta tutto il sistema. 
Dovresti concludere sul perche' il fatto che tale file inerte sia un
com.somefuck.someotherfuck.plist dentro ~/Library/Preference o qualcosa
del genere lo renda profondamente diverso da un .somefuck dentro ~.
-- 
-riko

 del genere lo renda profondamente diverso da un .somefuck dentro ~.
Non ho detto che sia relazionato, ho detto quello che fa spannometricamente 
(ovvero a occhio, percezione umana) il mio Tiger. Ci mette di più a caricare 
la sessione quando lo riavvio ora che un anno e mezzo fa quando lo 
reinstallai ex-novo dopo che si era fritto l'hard disk.
L'unica spiegazione logica che ci sarebbe (ma non so se sia così o meno, non 
conosco troppo gli internals di OSX) è che i vari file di configurazione, 
plist e cazzi e mazzi siano letti per qualche oscuro motivo all'avvio 
(quello che succede con Windows e il registro fondamentalmente). O magari è 
Quicksilver che impazzisce, dato che è l'unico programma che ho caricato 
all'avvio in background.
-- 
Vide

 
http://www.macupdate.com/info.php/id/19879/lingon
Grazie, ci darò un'occhiata.
-- 
Vide

 Dipende.
Mi sembra stiate dicendo la stessa cosa.

 Mi sembra stiate dicendo la stessa cosa.
Infatti :) Ho specificato "di soli programmi" apposta.
-- 
Vide

 assolutamente il metodo pi� efficiente.
Andiamo ad analizzare i fatti. Ho scritto un breve script che va a
spulciare in /Applications le varie librerie e vede le ripetizioni.
Ad un primo run mi ha dato ben 96 MB su 24.4 GB di applicazioni
presenti. Il che di per se costituisce meno dell'1% dello spazio
installato in applicazioni.
A questo punto sono andato a spulciare i dati. Ho scoperto che di questi
96 MB praticamente la totalita' dello spazio era da imputare ad una
famiglia di applicazioni scritte da una data software house che
utilizzano RealBasic per le loro applicazioni. Di fatto sono li
*puramente* per un'errore di questa sw house, e questo e' un errore
*loro*, non un problema sistematico. Specie in quanto hanno comunque
scelto di usare un installer che avrebbe potuto rendere inutile il
problema. La faccenda e' cosi' estesa perche' ho installato *tutte* le
loro applicazioni, visto che ho una licenza "globale" per tutto quello
che avevano fatto. E' roba che non uso e potrei cancellare.
Escludendo le applicazioni di questa sw house il tutto si riduce a 7.8
MB. Evito di calcolarti il totale percentuale di spazio occupato.
Io credo che una perdita di efficienza nell'ordine di 10 MB su 24 GB di
applicazioni installate, tenendo conto dei vantaggi dell'approccio
dovrebbe chiudere *quantitativamente* il discorso. Ovvero: lo spreco
c'e'. Ma e' trascurabile. Sui vantaggi spero siamo tutti d'accordo.
-- 
-riko

 Mi sembra stiate dicendo la stessa cosa.
No. Uno sta dicendo che il bicchiere e' 1/10 pieno, l'altro che e' 1/10
vuoto. :)
-- 
-riko

 vuoto. :)
9/10 pieno e 1/10 vuoto semmai :P
-- 
Vide

 c'e'. Ma e' trascurabile. Sui vantaggi spero siamo tutti d'accordo.
Ma il sensei non aveva pure pubblicato un intero paper sull'argomento? o
ricordo male?

 9/10 pieno e 1/10 vuoto semmai :P
Nope. Questo vorrebbe dire che state dicendo la stessa cosa.
-- 
-riko

 ricordo male?
Non ricordo.
-- 
-riko


Sensei:
| Se un OS e` un OS e non una accozzaglia di librerie usate da 3 persone, 
| e` coerente e completo. Da allo sviluppatore tutto cio` che serve per 
| produrre le proprie applicazioni e sperando, venderle (*). La completa 
| anarchia di linux ha portato a mettere ogni cazzo nei repository, 
| compresa roba che nessuno usa con la falsa idea che si risparmi spazio 
| oppure che la sicurezza aumenti. Questo e` falso (l'ho pubblicato, e 
| nell'articolo c'e` uno studio sulle shared libraries).

 
Mah, come ti dicevo io ho visto un'immensa differenza tra Win e Linux 
sull'uso della RAM proprio per questo discorso delle librerie; scommetto 
che OSX (e PC-BSD) hanno lo stesso problema di win e prosciugano molto 
pi� rapidamente la memoria di sistema avviando n applicazioni simili 
rispetto a un sistema con pi� lib condivise

 rispetto a un sistema con più lib condivise
Mah, quante applicazioni GTK o QT usi abitualmente su un sistema Windows o
OS X?
Molte applicazioni in GTK poi, per dire, sono in due versioni, con o senza
librerie GTK, o comunque puoi scegliere se installarle o no, se già le hai
shared.
E poi c'è il solito trade off: se A chiede la versione x e B la versione
x+1 dove la funzione foobar è stata deprecata, alterata, salcazzo, o ti si
sfancula A o non ti funziona B.
Preferisco sprecare un po' di RAM in più piuttosto che vedermi morire le
applicazioni sotto gli occhi (sono per la non violenza).
Vita vissuta, upgrade Ubuntu: GLib cambia malloc, tutto a un tratto non
vanno più VLC, pgAdmin, GIMP…

 Bando alle ciance, ci vieni al cloudcamp?
Quando, dove e come?
-- 
-riko

 OS X?
1 GTK.
di Qt ho... VirtualBox GUI (che ormai non uso piu').
P4V, ma in genere uso p4 da cli.
E un 
Analizzando i log del mio tool potrei averne anche un'altra... ma anche
quella non la uso mai.
Poi ovviamente su tutti i sistemi su cui sviluppo ho versioni aggiuntive
di Qt per lo sviluppo, ma quelle li non le conto: sono roba con cui
sviluppo.
Ho altri casi di una libreria in copie multiple *volutamente* per
lanciare test unitari su tutte le diverse versioni e vedere che non mi
si spacchi nulla. Non e' comunque il mestiere dell'utente. :)
-- 
-riko

 rispetto a un sistema con pi� lib condivise
Mi dispiace, hai perso la scomessa. Su PC-BSD non parlo, su OS X si. 
Tu immagini che OS X sia "Linux" senza apt o chi per lui e con un
pacchettizzamento bislacco. Non e' cosi'. 
Se vuoi scommettere, ti consiglio di farlo dove se vinci almeno diventi
ricco. Se vuoi parlare di informatica, non scommettere. Dimostra. :)
-- 
-riko

 P4V, ma in genere uso p4 da cli.
...quindi c'� poco da sharare :)

 sfancula A o non ti funziona B.
sì quoto, infatti molti prodotti danno le librerie "in bundle" proprio 
per sollevarsi da problemi di librerie con versioni non compatibili (o 
non ben testate)

 non ben testate)
...quindi? non ti lamentavi del consumo eccessivo di RAM? :D

 non sono GTK, sono XUL
ops, ovviamente solo FF e TB, openoffice usa un terzo toolkit suo

 ricco. Se vuoi parlare di informatica, non scommettere. Dimostra. :)
� una dimostrazione un po' difficile senza Mac, ma facciamola lo stesso.
prendiamo un programma che probabilmente usi spesso e che di solito 
viene tenuto in background, quindi dovrebbe stare molto attento all'uso 
di risorse: SKYPE
su linux puoi scaricare la versione con le qt statiche o dinamiche, 
scritto esplicitamente qui: 
http://www.skype.com/intl/it/download/skype/linux/choose/
guarda nei due package cosa trovi:
- nella versione con QT dinamiche l'eseguibile occupa 18 MB
- nella versione con QT statiche l'eseguibile occupa 26 MB
ovviamente se per Mac non hai la scelta statiche/dinamiche � perch� sono 
STATICHE e quindi � dimostrato che appena esegui un'altra applicazione 
QT4 (es. google earth) stai cacciando via pi� o meno 8 MB RAM e il 
programma si avvia pi� lentamente perch� deve ricaricare queste lib.
moltiplica questo fatto per n-volte (io ora su win ho 60 processi attivi 
al momento e forse una met� si appoggia ai soliti 3-4 framework tipici) 
e fai le tue considerazioni

 
http://www.cloudcamp.com/?page_id=1213
TY. Me lo ero perso. :)
-- 
-riko

 ...quindi c'� poco da sharare :)
Gia'. :)
-- 
-riko

 e fai le tue considerazioni
Sei fuori strada. Non esistono sessanta applicazioni Qt che vengono
usate comunemente sotto OS X. Non *esistono*. Figurati se uno le avvia
tutte insieme. Ma non ne esistono manco 10. Al momento ho oltre 100
processi attivi. Buona parte di questi non sono grafici. 
Al momento ho aperte *tutte* applicazioni Cocoa, *una* applicazione
Carbon e *una* applicazione non so che cazzo sia, visto che non
assomiglia a Cocoa (eppure linka Cocoa e Carbon). Che poi e' DrScheme.
Firefox sotto OS X si appoggia a Carbon (o forse Cocoa). OpenOffice
ormai e' Cocoa. 
Il tuo problema dei toolkit grafici esiste sotto Linux. Sotto OS X oltre
il 90% delle GUI e' Cocoa. Qt e' passabile e relativamente poco usato. 
GTK gira solo sotto X11 o in alpha. wx e' una pena.
Librerie infrastrutturali sono generalmente fornite con OS X, e comunque
nelle varie librerie Core di Apple c'e' piu' di quello che uno
sviluppatore necessita in una vita.
Qua e' praticamente tutto linkato dinamicamente. Solo che buona parte
del codice utile da chiamare e' gia' nell'OS. Il codice specifico
ovviamente no, ma quello e' anche difficile duplicarlo.
Di fatto la tua obiezione si applica *solo* a Qt. Che come dicevo e'
purtroppo usata meno di quello che merita.
-- 
-riko


almeno su linux/unix XUL usa GTK per l'interfaccia utente.. infatti hai 
GTK come dipendenza se vuoi installare ff/tb ed inoltre i widget, le 
finestre di "Apri file" ecc. sono quelle GTK anche se sei su KDE.
Non so se su win e mac riescano ad aggirare il tutto ed appoggiarsi 
direttamente ai widget nativi.

 direttamente ai widget nativi.
Ma ovviamente scusa.
Non so dirti se su OS X si appoggi a Carbon o a Cocoa, ma di certo non
si appoggia a GTK. GTK ha bisogno di X11, fortunatamente firefox no. 
XUL nasce apposta per essere *staccato* dal toolkit sottostante. 
-- 
-riko

 direttamente ai widget nativi.
Ma ovviamente scusa.


 direttamente ai widget nativi.
in realt�, in XUL non vengono usati realmente i widget nativi (se non per
le finestre apri file ecc che tu appunto indichi), hanno semplicemente lo
stesso aspetto; stessa cosa in Windows, e credo anche Mac.
� pi� o meno quello che succede con il tema WIMP di GTK sotto Windows.

 Nope. Questo vorrebbe dire che state dicendo la stessa cosa.
Ma infatti stiamo dicendo la stessa cosa, dato che nessuno può affermare che 
il 100% del software su OSX si può installare con drag'n'drop. Solo che lui 
vede il bicchiere pieno, e dice "praticamente tutto si, a parte eccezioni", 
io vedo quello vuoto e dico "non esiste al giorno d'oggi sistema consumer in 
cui tutto il software si installi col dnd".
-- 
Vide


Scusa, ma sarebbe anche una bella confusione se dovessi droppare una
icona che poi non trovo più dove l'ho droppata, e devo andarmela a
cercare nel pannello delle preferenze.
  ngw

 cercare nel pannello delle preferenze.
Non ho capito :) 
-- 
Vide