Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
ciao Vincenzo,
ti faccio i complimenti di persona per l'iniziativa e penso di dedicargli un post sul mio blog (anche se da profano, dato che non posso scaricare e testare L.T.).
Effettivamente la tua idea avrà modo di aiutare molti novizi di GNU/Linux, tuttavia in via del tutto personale (e ripeto sempre che ciò che mi piace e ciò che è buono non sempre coincidono) sono un amante del sistema di dipendenze e organizzazione originale, per puro controllo verso il sistema (non amo neanche troppo synaptic figurati e a volte non disdegno la compilazione diretta).
Però credo nell'iniziativa.
Quanto hai scritto chiarisce parecchi dubbi sul sistema, anche se non ho ben compreso una cosa dal post precedente.
Se io ho bisogno di gimp, carico gimp.sfs che a sua volta carica gimp+xlib+ylib. Poi ho bisogno di krita; carico krita.sfs e a sua volta carica krita+xlib+wlib. Ma in ram avrò 2 xlib caricate???
Oppure il sistema se ne accorge che xlib gia è caricata ed evita l'esecuzione?
Se volete saperne di più scaricate il codice sorgente di sfslauncher v0.2 è OpenSource (GPL) l'ho scritto in pascal, ma posso tranquillamente convertirlo in c++, magari per fare un porting su un altro sistema.
Essendo un *programma di sistema* non sarebbe meglio optare per il C?
"(creare pacchetti che includono anche le librerie necessarie agli eseguibili, cosicche' ogni eseguibile porti con se una copia personale delle librerie cui e' linkato) quasi equivalente a linkare staticamente ogni eseguibile;"
Nell'idea definita CRETINA, tutto questo era previsto !
Il software contenuto nel pacchetto sfs non è ricompilato per puntare direttamente (linking statico) alle librerie contenute nel pacchetto, ma cercherà (come qualsiasi altra applicazione linux) la libreria nella $library_path ( ad es. /usr/lib) del S.O. . Uno script bash contenuto nel pacchetto sfs provvederà ad esportare la path delle librerie con se trasportate nella library_path del sistema operativo.
Quindi la libreria interessata verrà caricata una sola volte in memoria (nello spazio degli indirizzi dell'applicazione) e riutilizzabile anche da un'altra applicazione.
Un esempio chiarrà meglio il concetto:
Diciamo di avere 2 file programmaA.sfs e programmaB.sfs . Entrambi condividono una libreria chiamata libX.so che è contenuta tutti e due i pacchetti nella sotto directory lib/ di ogni pacchetto sfs.
Nel pacchetto sfs c'è uno script bash come questo :
questo script esporta la path delle librerie contenute nel pacchetto sfs nella libreria LD_LIBRARY_PATH del S.O. .
Poi viene lanciato il programma, che cercherà la libreria in ordine, prima nelle directory predefinite come /usr/lib e se ( e solo se) non la trova, continua la ricerca nella sottodirectory del pacchetto sfs, dove la trova.
Mentre il programmaA è in esecuzione lanciamo anche il programmaB il quale esporta la sua path di librerie nell' LD_LIBRARY_PATH, poi viene l'anciata l'applicazione contenuta nel pacchetto programmaB.sfs che incomincerà la ricerca della libreria. Esso cercherà la libreria prima nelle path di default (/usr/lib) senza trovarla, poi nel percorso "lib/" precedentemente esportato che è quello del prgrammaA, puntando quindi alla stessa libreria utilizzata dal programmaA.
Se nel frattempo il programmaA viene chiuso, si possono verificare 2 condizioni :
O la libreria è totalmente caricata in memoria, quindi il programmaB può continuare la sua esecuzione tranquillamente.
O se si ha un accesso continuo alla libreria (ad esempio un DynamicCall) e il processo detiene un lock sul file della libreria, sfslauncher non riuscirà a smontare il pacchetto sfs. Anche qui non c'è da preoccuparsi, inquanto al prossimo riavvio della macchina tutti questi pseudo-filesystem montati verranno forzatamente smontati durante lo spegnimento.
Quindi per chi non l'avesse capito:
--- Il linking è dinamico
--- Nessun file viene scritto nell'hard disk, lasciando inalterata la configurazione di base del sistema operativo.
Ci tengo a dire che il software contenuto nel pacchetto sfs non è ricompilato proprio! Si usano gli eseguibili contenuti nei pacchetti debian.
Spero di essere stato chiaro !
Grazie Blizzard per il tuo interessamento, sono convinto che "il bello" del free software sia proprio questo, cioè il potersi confrontare , lavorare insieme e far nascere idee originali. Linux viene spesso considerato ostico come sistema da una buona fetta di utenti, invece io sono convinto che linux sia veramente il futuro ! Qui termino il mio post con le parole di un famoso filosofo illuminista:
Ogni uomo, scriveva Kant, ha la vocazione a pensare da sé; e rispondere a questa vocazione è tanto più importante, se non lo si fa da solo, nella sua stanza, ma in pubblico, assieme con gli altri. Chi è isolato, per pensare da sé, deve anche pensare da solo: e questo si fa con fatica, tanto che molti preferiscono affidarsi, come bambini, alla direzione di altri. Ma se qualcuno che ha fatto lo sforzo di ragionare da sé condivide i suoi risultati, sarà più facile che anche altri si convincano ad assaggiare il sapore della libertà.
Ueila' grazie Vincenzo dei chiarimenti!
E' interessante tutto questo...piu' che altro perche' e' una possibilita' che non mi era mai passata per la mente e quindi mi domando quali altri scenari si possano prospettare per il futuro del software libero
ciao,
sinceramente questo modo di procedere mi porta a pensare ad un possibile utilizzo del metodo nel mondo videoludico.
Senz'altro fornirebbe alle software house un modo di porre il prodotto in un modus operandi simile alle consoles, riducendo il rischio di vedere i propri giocatori che devono andarsi a cercare SDL/OpenAL ecc...
In fondo il gioco su pc, tranne RARISSIME eccezioni dovute a pochi giochi di rete, occupa le complete risorse della macchina.
Chiederei pertanto a Vincenzo di puntare anche su questo aspetto, mostrando come ad esempio come un gioco alla stregua di UT o Serious Sam II o Quake * possa essere utilizzato sotto questa tecnologia(Ovviamente il megafile dovrebbe contenere anche i gamedata, quindi non si può rilasciare. Però sarebbe buono far vedere che la cosa funziona ed è semplice, in caso future sviluppatrici intendessero considerare il pinguino).
Certo, anche una applicazione videoludica del formato non sarebbe male, ad esempio nella pagina dei download del mio sito c'è un gioco 3D chiamato Trackball 3D che contiene tutte le risorse per essere eseguito.
Comunque convertire programmi nel formato SFS è veramente facile... bisogna solo conoscere un pò Linux e saper un pò programmare in BASH.
Chiunque voglia divertirsi nel generare applicazioni in questo formato è libero di farlo.
Ciao
Vincenzo Dentamaro
1) non sta scritto da nessuna parte che programmaA e programmaB pur portando con se le zlib, queste ultime siano la stessa versione; ad esempio programmaA puo' esser linkato a libz.so.1.2.2 e programmaB a libz.so.1.2.3; in tal caso se si lancia un'istanza di programmaA e una di programmaB, verranno caricate entrambe le librerie
2) come gia ha accennato vincenzo con questo sistema diventa impossibile (fintanto che la libreria e' in uso) disinstallare un pacchetto se qualsiasi altro programma linkato ad una libreria contenuta nel pacchetto da disinstallare locka quella libreria
Ok, ma per quanto riguarda il problema delle librerie non è niente di più di qullo che accade in un normale sistema linux.
Volendo si può creare un link simbolico chiamato libz.so ad una libreria (magari la versione più recente) ed esportarla (ci sono tante soluzioni), comunque mi sembra che ci stiamo attaccando alle briciole.....
" 2) come gia ha accennato vincenzo con questo sistema diventa impossibile (fintanto che la libreria e' in uso) disinstallare un pacchetto se qualsiasi altro programma linkato ad una libreria contenuta nel pacchetto da disinstallare locka quella libreria "
Questo accade molto raramente, inquanto la maggiorparte delle librerie viene caricata in memoria al lancio della applicazione e le sue funzioni vengono mappate ed esportate all'eseguibile (ma essa è in memoria), e per questo sfslauncher può tranquillamente smontare il filesystem.
Come dicevo questo accade solo con delle dynamic call, ed in vita mia gli unici programmi che ho visto e che fanno largo uso di dynamic call sono Winamp o Xmms.
Comunque l'ostacolo è stato ormai raggirato dalla versione 0.3.
il tutto davvero molto interessante , che può aprire prospettive e idee nuove su linux...
penso anch'io come blizzard che questo sistema potrebbe essere utilissimo per i videogiochi, in pratica funzionando il pc come una console e comunque un progetto da seguire con attenzione...
vincenzo ha scritto:Ok, ma per quanto riguarda il problema delle librerie non è niente di più di qullo che accade in un normale sistema linux.
certo, per questo in decenni la soluzione meno peggio che si e' trovata e' quella delle "distribuzioni" in cui ogni pacchetto viene compilato contro le medesime versioni delle librerie, che poi vengono a loro volta pacchettizzate
Volendo si può creare un link simbolico chiamato libz.so ad una libreria (magari la versione più recente) ed esportarla (ci sono tante soluzioni),
comunque mi sembra che ci stiamo attaccando alle briciole.....
non ti offendere ma credi davvero di avere avuto la pensata geniale che migliaia di informatici dal 1964 (introduzione del dynamic linking con multics) non hanno avuto? l'attuale sistema (pacchettizzare tutto il software in modo che linki le medesime versioni di librerie gia pacchettizzate) non e' perfetto (su sistemi operativi, che non hanno una distribuzione centralizzata, ma caotica come ad esempio gnu/linux che conta centinaia di distro, rende problematica la distribuzione di software in binari da parte di terze parti, obbligando a fare N pacchetti differenti) ma e' la soluzione meno peggio; sicuramente meglio di installare pacchetti che si portano dietro le proprie librerie (con il rischio, gia menzionato, di ritrovarsi caricate N istanze della medesima libreria con differenti versioni)
e a volte non disdegno la compilazione diretta).
