Newsgroup: it.comp.os.dibattiti
Titolo: Come si potrebbero migliorare gli unix?

Ciao a tutti,
Stamane, preso da fancazzismo incredibile, mi sono messo a pensare a come
poter migliorare gli unix attuali con tecnologie che esistono già e che non
vengono implementate per vari motivi... (lo so è un discorso da bar ma del
resto l'ho premesso che sono preso da fancazzismo ;) )
Il mio unix-like perfetto per il desktop dovrebbe avere un kernel con api
per i driver stabili (magari non con licenza GPL per evitare problemi
legali con i driver closed-source).
Inoltre vorrei tanto che qualcosa di simile al progetto elektra
(
http://elektra.g4ii.com/Main_Page
) venisse utilizzato per i file di
configurazione e magari pure per init. In questo modo ci sarebbe una sorta
di standardizzazione, senza considerare il fatto che sarebbe molto più
facile IMHO creare interfacce grafiche per configurazioni e wizard. Pensate
a come sarebbe più comodo installare un driver binario (come ad esempio
quelli nvidia) che si installa e si configura automaticamente attraverso
dello chiamate api (senza preoccuparsi se il file di X sta
in /etc/X11/xorg.conf o in altri posti arcani...).
Un'altra cosa che vorrei cambiare è il sistema di installazione dei
programmi... Non penso che il sistema dei repository sia il sistema
perfetto, in quanto risulta comodo solo se il programma che ti serve sta
nel repository e sia aggiornato e se l'utente abbia una connessione veloce.
Se una delle due cose cose cade, povero utente... Per me la soluzione
migliore è creare un "core" ampliato, cioè una serie di librerie che si sa
che staranno in ogni sistema desktop (tipo X11+qt+kdelibs o
x11+gtk+gnomelibs) e da li creare dei pacchetti sullo stile dei pbi di
pcbsd, pacchetti autoinstallanti che contengono il programma e le librerie
extra a quelle base. Inoltre mi piacerebbe che i pacchetti che non
contengano driver potessero essere installati anche nella tua home senza
per forza scomodare una installazione in tutto il sistema. Mi spiego.
Scarico il pacchetto amarok.pbi. Faccio doppio click e mi appare la
richiesta di installazione con due scelte, installazione di sistema (che
richiede la password di root) e installazione nella mia home. Quest'ultima
non solo non mi richiede la password di root, ma installa il programma
dentro ~/.Programs/Amarok e che mi crea i link simbolici dei binari in
~/Programs/Amarok. In questo modo si risolve pure un altro problema che ho
riscontrato nei sistemi Unix-like, cioè che se il software non sta nel menu
del desktop manager non esiste :)
Infine i pacchetti creati con questo ipotetico packet manager dovrebbero
contenere anche la versione dell'os a cui si riferiscono, in modo che,
unito alla standardizzazione delle librerie base, sia possibile installare
un programma vecchio di 5 anni insieme ad un altro pacchetto che contiene
appunto le librerie di 5 anni prima (e magari aggiungendo una voce al file
manager tipo "Avvia come NewOs 1.0", voce che modifica per quel programma
il ldpath)
Vabbè dove aver scritto questa inutile marea di parole (pure in un italiano
approsimativo) su un ipotetico os che potrebbe piacere solo a me torno a
lavorare va...

"Coma" <nigh...@inbox.lv.INVALID> ha scritto nel messaggio 
news:GvD4h.1750$GM5...@tornado.fastwebnet.it...

Giuro.... non è un mio fake, eh.....

 Giuro.... non è un mio fake, eh.....
io mi fido, ma quotare meglio...?
-- 
NoWhereMan
-- NoWhereBlog: 
www.nowhereland.it
-- FlatPress: 
http://flatpress.nowhereland.it
 blog flat-file powered,
xhtml1.1strict compliant
-- deviantArt: 
http://nowhereland.deviantart.com

 del desktop manager non esiste :)
Questa dove l'hai vista?
...
ciao ;)


 legali con i driver closed-source).
Tu li vedi tutti questi driver proprietari sviluppati per FreeBSD che
offre API/ABI stabili e non GPL?
-- 
Tobe Bofh

 la vedo dura :D
La vera soluzione sarebbe quella di unificare tutti i toolkit Linux +
Wine in modo che le finestre load/save, le finestre di stampa ecc.
ecc. fossero identiche in ogni applicazione.
Saluti
Pegasus

 resto l'ho premesso che sono preso da fancazzismo ;) )
Cominciando dal buttar via le guerre di religione in tutti i sensi.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 Cominciando dal buttar via le guerre di religione in tutti i sensi.
Un apostata della religione della mela? ;)
-- 
Tobe Bofh



Rileggi: buttandole via le religioni, e certo non creandone di nuove.


 Rileggi: buttandole via le religioni, e certo non creandone di nuove.
Apostata -> Colui che ripudia pubblicamente la propria religione. ;)
-- 
Tobe Bofh

 ciao ;)
Ciao :D 

 ecc. fossero identiche in ogni applicazione.
Questo è semplicemente impossibile. Con le Qt4 si sta iniziando una
convergenza almeno grafica, ma un'unificazione è impensabile. Senza contare
Wine... non ne parliamo nemmeno. Non è solo che manchi la volontà è che
proprio non è possibile *fisicamente*.


 il ldpath)
questo in debian e dirivate esiste da tanti di quegli anni che non
ricordo quando l'hanno inserito. Ecco perché puoi avere varie versioni
dello stesso programma e delle stesse librerie.
Complimenti per la scoperta dell'acqua calda.

 ecc. fossero identiche in ogni applicazione.
mai letto nulla di portland? :-)

 menù... 
non è che non c'è, allora, non sai dov'è--- questo è un altro discorso... 
whereis nomecomando 
ciao


 Complimenti per la scoperta dell'acqua calda.
Ok quindi scopro con agilità che molte delle cose che ho detto erano
castronerie. Molto bene :D:D:D
Vabbè, son qua anche per imparare



E' possibile perchè tu scrivi delle metalibrerie che all'esterno esportano 
l'ABI e
l'API di Win32, QT, GTK+ ecc. ecc. ecc., e poi implementano tali 
funzionalità
per mezzo di un meccanismo che traduce le varie chiamate riconducendole
a quelle di un layer comune.
It's simple.
Saluti
Pegasus

 It's simple.
It's slow. :P
ciauz!


 Complimenti per la scoperta dell'acqua calda.
E' che oggi faceva freddo e ho avuto l'intuizione ;)
Ps forse non si è capito nella mia introduzione che quando parlavo
di "tecnologie che esistono già", parlavo di cose già attuabili ed
esistenti, ma non rifinite né istituzionalizzate...


Non credo, l'overhead di conversione non sarebbe poi così elevato, anzi
secondo me il sistema alla fine diventerebbe addirittura più veloce.
Saluti
Pegasus

 ciao
ciao

 resto l'ho premesso che sono preso da fancazzismo ;) )
....
potresti cominciare da qui:
http://www.f2s2.org/index.php?lang=it&page=home
per poi arrivare qui:
http://www.f2s2.org/index.php?lang=it&page=supporto_firma
siamo dei sognatori e degli invasati, però ci proviamo.
saluti
d.aniele 

 ciao :)
Per favore, ti imploro di non stimolare la galoppante fantasia di
Pegasus/Vegeta in tema di "come ti faccio l'OS perfetto"...non ho manco
voglia di saltarle le pappardelle che poi scrive.
-- 
Vide

 voglia di saltarle le pappardelle che poi scrive.
Mi inserisco qua per dire che personalmente non sono Vegeta, né Pegasus, non
conosco Anna né uso Powerpoint :D Sono semplicemente uno stupido utente
Linux da parecchio ormai (dalla Mandrake 8.2 + o -) e che, pur
utilizzandolo e apprezzandolo, non può fare a meno di notare che non sta
veramente "avanzando" nel lato desktop, ma solo in quello server e (forse)
corporate... E, paradossalmente, prima si scommetteva molto di più sul lato
desktop, o quantomeno small business, tantè che esisteva la Corel, che
aveva portato, seppur in modo raffazzonato  (mi sembra tramite wine, ma non
mi ricordo bene...) i suoi prodotti. Ed esisteva la loki, che aveva portato
i videogiochi in questo sistema. E adesso non ci sono più compagnie
equivalenti a queste sul mercato... Eppure teoricamente ogni anno è l'"anno
di linux" e come ogni anno manca l'interesse commerciale in questi campi,
nonostante potenzialmente sia un mercato più ampio del mercato di nicchia
della apple, che di compagnie simile a loki e corel ne ha abbastanza.
Allora mi chiedo se non sia un problema della piattorma, della sua mancanza
di omogeneità e come lo risolverei... 

 della sua mancanza di omogeneità e come lo risolverei...
Ammazza, siamo già al "si stava meglio quando si stava peggio"? per
me "l'anno di linux sul desktop" è una boiata in toto, e vedrei come
risultato *enorme* se Linux arrivasse un giorno a metà della penetrazione
di Firefox. Detto questo, mi pare che la situazione invece sia migliorata
eccome col passare del tempo, ma non poteva essere altrimenti (peggio era
difficile fare, insomma :P).
-- 
Vide

 esistenti, ma non rifinite né istituzionalizzate...
seocndo me l'unica cosa veramente sensata che potrebbe venire fuori è un
tool a plugin per gnome/kde per la configurazione dei server o dei
programmi. Ma il tool da solo non può supportare tutti i progrmmi,
servono i plugin e l'onere dei vessere dei programmi non del tool di
configurazione.

 It's simple.
una volta era partito un progetto simile se ricordo bene. non ha mai
partorito nulla di sensato. non è banale anche per via dei binding, qui
avresti bisogno di un blocco di software che si attacchi dappertutto e
ti esporti tutti i binding.... Fattibile è fattibile, ma è difficile.
Penso che avresti il toolkit definitivo.

 secondo me il sistema alla fine diventerebbe addirittura più veloce.
credo che l'overhead non sarebbe terribile. però la difficoltà di
scriverlo sì-...

> e quindi non disinstallabili, sarebbe meglio.
hhhhmmmm 'mmmah...
ciao




Usare un OS e` diventato una religione? Siamo messi male...


 non mi sembrano difficili.
Credo che la questione sia: com'e` che siamo tornati indietro al 1978 
con i terminali e la riga di comando per uno stupido gioco?
Vabbe` che ho riusato il vecchio prodest pc128 qualche settimana fa per 
il gusto retro` (lacrimuccia con la piramide...) pero` mi sembra 
eccessivo questo...
Dipende sempre da cosa vuole la gente a cui ti rivolgi, certo. 
All'ubergeek non importa nulla di andar di cc/ld, ma se vuoi 
acclappiare piu` gente possibile devi un po' far tattica stile 
"rosetta" di apple, pare stupido ma serve... anche questo. La gente 
comune  (se ti rivolgi a loro) vuole una cosa tipo "just works", come 
l'automobile: chiavi, benzina e basta. Se riscontri i primi problemi 
tipo "le candele EX871/H sono compatibili con EX871/H1 ma hanno minore 
potenza e non le devi usare, quindi toglile cambiale e riprova", credo 
che perderai e di brutto.
Non poco tempo fa infatti sull'argomento qualcuno si lamentava del 
fatto che linux stia diventando, nonostante gli sforzi, per ubergeek 
server, e non per uberdummies desktop. Anche ubuntu s'e` buttata sul 
server con il long time support...
E` un rischio. Direi anche concreto.


 Penso che avresti il toolkit definitivo.
Sempre che azzecchi l'API giusta se no giu di fork.
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 
Pentiti e convertiti, infedele!
Altrimenti riceverai a casa la visita di Sant'Ignutius da Nuova York:
http://snipurl.com/11u9f
;)
-- 
Tobe Bofh


Esiste. Si chiama Mac OS X :)

 Quello è perché le dipendenze in quel caso sono gestite male IMO
lì il problema è più grosso: non è facile scorporare gecko da firefox o
mozilla. Penso che sarebbe un grande passo avanti per firefox, ma da
quello che ho capito è veramente difficile.

 Sempre che azzecchi l'API giusta se no giu di fork.
be... sinceramente non coredo che sia difficile. Il tool, senza i plguin
dovrebbe solo fornire funzionalità tipo apri file, e salva file. Se poi
si volesse fare gli sboroni si potrebbe usare anche apertura di file su
computer remoti per amminstrare server (via ssh o simili) e magari
salvare i file di configurazione su un cvs per avere lo storico.
Il resto sarebbe compito dei plugin.

 difficile fare, insomma :P).
Beh migliorata è migliorata, se anche la mia ragazza riesce ad usare ubuntu
+ o - (e sarebbe anche meglio se riuscissi a far funzionare quei maledetti
driver per il modem), però concordi con me che ci sono molte meno aziende
che scommettono in una visione desktop di linux/bsd (novell, sun e ibm sono
aziende dedicate ai server e ai sistemi corporate). E senza aziende che
scommettono, sarà sempre un mercato di nicchia, senza un vero "appeal" per
l'utente comune...  

 configurazione.
Ma una standardizzazione potrebbe certamente aiutare, Imho :D

 Esiste. Si chiama Mac OS X :)
Lo so :D Infatti penso che il mio futuro computer sarà un mac :D 

 quello che ho capito è veramente difficile.
non si può scorporare una libgecko ? cheppalle!


 non si può scorporare una libgecko ? cheppalle!
da quello che ho capito non è così banale. anzi. purtroppo.
però avevo letto che in mozilla ci stavano studiando su.

 Ma una standardizzazione potrebbe certamente aiutare, Imho :D
senti, in debian ci sono 18279 pacchetti. Li metti tutti daccordo tu?
Non esiste nemmeno su windows questo....

 caricate le nuove gtk sai quanto pacchetti dovrebbero essere rifatti? :-)
ahhh, okk, ma così funziona solo con i pacchetti sorgente
scarichi le build-dep così hai anche le dipendenze di build.
es apt-get build-dep nomepacchettosorgente
poi c'entra qualcosa un apt-source mi pare :/
ma se sono tarball è un po' diverso


 
non si puo'
-- 
|L|E|L|E|

 ma se sono tarball è un po' diverso
no, quando per esempio compili il deb con dpkg-buildpackage e simili si
ricordano a cosa è linkato. non sono le builddep, sono qualcosa di
simile, non ricordo adesso di preciso.

 firefox da 1.0 a 1.5....
No, il problema era che disinstallando firefox 1.0, il sistema si portava
via anche componenti essenziali per la GUI del sistema operativo
(e poi la GUI non partiva più....)

 (e poi la GUI non partiva più....)
no, non partiva yelp, il visualizzatore dell'help, che per fare il
redering delle pagine usa gecko. adesso, tra il fatto che non vada uno
opiù applicazioni che di basano su gecko e dire che non parte tutta la
grafica ne passa... Gnome senza gecko funziona eccome, non hai il
browser internet e yelp.


La vera questione è che il gestore pacchetti ha bisogno di registrare dei
componenti nel sistema. Non si tratta solo di copiare librerie.
Per esempio, se installo la nuova applicazione Bluetooth, voglio che quando
faccio clic con il tasto destro in KDE o Gnome su un file, mi appaia
"Invia come Bluetooth".
Allo stato attuale, questo viene fatto lasciando a chi fa lo script di 
installazione
l'incombenza di modificare i file (di testo) necessari in Gnome e KDE.
La cosa ha delle conseguenze precise.
Per esempio: se si crea un nuovo window manager, o questo si incarica di
guardare nei file di configurazione di Gnome e KDE, oppure tutti gli script
di installazione devono essere riscritti in modo da registrarsi anche sotto
il nuovo window manager.
Seconda cosa: se si cambia il formato dei file di configurazione, allora 
sono
cazzi: gli script di installazione delle applicazioni cessano di funzionare
(almenochè non te li tieni per ragioni di retrocompatibilità, ciò che si
fa sotto Windows NT per SYSTEM.INI).
Ora, se l'installer fosse un processo che si interfaccia ad un daemon che 
gira
in background (o che usa una libreria, vedi un pò tu), la cosa potrebbe 
essere
gestita in modo diverso.
Il terzo, quarto, quinto, sesto nuovo window manager che creiamo si limitano
a registrare delle callback nel gestore di installazione integrato nell'os
(ossia, proprio in quel daemon che gira in background che voglio io e che
non c'è attualmente....)
In questo modo, quando il programma di installazione cerca di registrarsi
nel sistema, viene eseguita la callback per il nuovo window manager,
che provvede a registrare ciò che vuole il programma in modo compatibile
con i propri formati di file di configurazione, eventualmente stoppando
o ignorando le richieste che non hanno senso nel contesto del nuovo 
ambiente.
In altre parole, il processo di setup dell'applicazione Bluetooth Wildcomm
chiederebbe di registrare una nuova voce nel menù di tasto destro: il
componente del sistema operativo che si occupa 
dell'installazione/disinstallazione
provvederebbe prima a chiamare la callback di KDE, che registra la
nuova voce nel file kdeconf, poi chiamerebbe la callback di Gnome,
che registra la voce nel registro di Gnome, poi chiamerebbe la callback
di Enlightnen che registra la voce nei suoi file di configurazione, poi
chiamerebbe la callback di Nanodesktop che ignorerebbe l'operazione
perchè non gestisce tasti destri ecc. ecc. ecc.
Naturalmente, così puoi cambiare il formato dei tuoi file di configurazione
(passare da testo a binario per esempio), senza che i processi che si
occupano delle installazioni se ne accorgano.
Seconda questione: supponi che qualcuno riesca a riunificare QT, GTK+
e libreria Windows alla Wine.
Bene, per compatibilità con le applicazioni preesistenti, tu dovresti 
fornire
delle librerie fake per le QT e le GTK+. Ossia librerie di pochi kb che
esportano all'esterno le funzioni con i medesimi prototipi delle librerie
originarie, ma che internamente si limitano a convertire le chiamate in
qualcosa di compatibile con il layer comune che esiste sotto.
Ora, quindi ciò significa che tu hai una libqt.so.2 in /lib che in realtà 
non
è la vera libreria di Trolltech ma è una fake library.
Se qualcuno cerca di installare un pacchetto RPM che contiene la vera
libqt.so.2, questa operazione deve essere bloccata, ma senza impedire
l'installazione di tutto il pacchetto. Questo è impossibile con i sistemi
attuali, perchè Yast ad esempio si limita a chiedere la password di
root e poi in background esegue l'RPM con urpmi (mi sembra, comunque
il concetto è quello...), che si limiterebbe a copiare le librerie del
pacchetto (sovrascrivendo la fake libqt.so.2 con la propria).
Se invece blocchi libqt.so.2 con dei permessi speciali, allora il gestore
pacchetti interromperà il processo di installazione di tutto l'applicativo.
E sempre nei guai sei.
Ora, supponiamo che il setup di un pacchetto sia un processo invece
di uno script.
Bene, questo processo richiama una funzione C per installare la sua 
libqt.so.2.
L'API intercetta la chiamata, mostra un messaggio sulla GUI per spiegare che
il processo di installazione della libreria viene emulato e che la fake 
library
in realtà non sarà toccata, poi restituisce all'installer un bel codice di
ritorno 0, in modo che il programma di setup **si illuda** di avere
effettivamente copiato la propria libreria nel sistema e prosegua il
processo di installazione (in realtà rimane sul disco la fake library).
Puoi fare tutto questo con gli attuali script eseguiti da bash?
Ciao
Pegasus

 
Non ci sono problemi, io leggo solo la pagina che apro, se devo fare lo 
scroll la chiudo. Semplice?

 scroll la chiudo. Semplice?
be' così forse è un po' troppo :D


 lavorare va...
Esatto. 

 Puoi fare tutto questo con gli attuali script eseguiti da bash?
per quello che rigurda l'architetture deb sì, per quella rpm non lo so
di preciso, ma anche qua credo che sia la stessa cosa, forse con un nome
lievemente diverso.

 Esiste. Si chiama Mac OS X :)
MacOS X risolvfe molti problemi tradizionali dei sistemi GNU/Linux.
Specialmente porta l'usabilita' ad altri livelli.
Ma nemmeno lui e' perfetto, eh. Se lo vogliamo vedere come una 
panacea, sbagliamo tanto quanto quelli che lo denigrano senza 
conoscerlo.
Ha tante cose belle. Ma ha anche tante cose migliorabili.
Alcune di queste lo saranno in Leopard. Altre no.
Sistema di pacchetti integrato anyone?
-- 
RiK0

 Sistema di pacchetti integrato anyone?
No ti prego, basta migliorare un po' i bundles ed e' il mio Valhalla.
Proprio dovessi chiedere, mi piacerebbe che i ports fossero un po' meglio, ma
tutto qui.
  ngw

 installazione allora sarai comunque fregato.
Tranne per le ovvie eccezioni, si puo` eliminare del tutto il concetto 
di ``installazione'', con un bel bundle. Apple/NeXT e 
BeOS/Haiku/(Zeta?) avevano questo.


 Sistema di pacchetti integrato anyone?
Prego iddio di no: e` la scelta peggiore che si possa fare.


 tutto qui.
Già, basterebbe sistemare i bachi.
...aspettando Leopard



Ehm.... no.... non mi sembra....
Poi, quando un povero disgraziato utente vorrà installare il pacchetto
X, questo richiederà la libreria qt2.0.lib ed apt, tutto bello contento, si
scaricherà il pacchetto che provides qt2.0.lib (quelle vere no?) e tutto
bello contento se le installerà sul disco, relinkando con ldconfig.
Peccato che le nuove librerie qt2.0 contengono il codice tradizionale
per l'interfacciamento con X, e non sono le librerie fake qt che rinviano
tutto ad un layer comune. Risultato: sistema danneggiato e buonanotte.
A meno che uno non si faccia l'ennesimo repository (il nr. 837.873 della
serie) nel quale le librerie qt sono distribuite in versione fake e non 
nella
versione tradizionale.
E siamo sempre al solito problema di fondo degli Unix......
Ciao
Pegasus

 
ma se in un pacchetto che ilcomano che va a cancellare file alla cazzo....

 consente all'installer di portare a termine il suo lavoro.
ma ma cose serve illudere? hai soluzioni molto più preceise. ALtrimenti
hai un sistema che non sa bene cosa sta facendo. che culo!

siccome le qt2 hanno interfaccia diversa puoi avere il 3 fake e il 2
originale. sono due librerie distinte.
Senti, studiati come funzionano le librerie nel mondo reale, al di fuori
di quell'accorcchio non compilante di nanodesktop.

 meglio, ma tutto qui.
Si. Un po' meglio. E magari 'parte' del sistema, come avrebbero dovuto
essere (e non sono per mancanza di fondi/voglia etc).
Anche perche' se fossero integrati con il sistema, potrebbero anche
gestire i vari pacchi open source integrati nel sistema. Ma vabbe'.
-- 
RiK0

 Prego iddio di no: e` la scelta peggiore che si possa fare.
Con integrato intendo dire darwin ports installati con i developer
tools e in grado di gestire anche il sw di base di MacOS X.
-- 
RiK0

 ma se in un pacchetto che ilcomano che va a cancellare file alla cazzo....
???
Perdona, ma scrivendo la tesi non ho gran che di cervello per comprendere :(


 tools e in grado di gestire anche il sw di base di MacOS X.
Forse e` troppo da geek.
Io di fink uso sicuramente latex, di altro veramente poco/nulla (non so 
altri quanto lo usino). Non e` proprio qualcosa di developer... ma se 
me l'avessero installato di default, io avrei goduto di buon grado 
(magari con un plugin XCode) ;)


 (magari con un plugin XCode) ;)
Io fink lo odio. Comunque sono d'accordo, averlo avuto...
Per XCode... uso TextMate per tutto. E' fantastico. Anzi, scherzavo. 
Non per tutto Prolog lo faccio con Emacs. Haskell meta' e meta'.
-- 
RiK0

 Io di fink uso sicuramente latex,
fermo lì!
io sto per cambiare portatile e vorrei prendere un macbook pro.
Come ti trovi con fink? Porca miseria, proprio latex è una delle cose
indispensabili, assieme al compilatore c.....
Non riesco bene a capire la differenza tra fink e darwinports. Sono due
progetti distinti e basta? in termini di qualità cosa credi che sia meglio?
dammi un paio di informazioni per piacere....
Grazie

 comprendere :(
ti capisco anche se a me tocca l'anno prossimo....
lui diceva che se l'installazione passa per un componente di sistema
allora tutto rimane in ordine. E ok.
Poi si è messo a dire che deb e rpm non vanno bene perché se non sono
fatti bene potrebbero sputtanare il sistema. Ed è vero.
peccato che questo sia vero per tutti i meccnismi di pacchettizzazione.
Il suo è un non problema, causato dal fatto che non sa come si sviluppa
un programma con un minimo di qualità.

 progetti distinti e basta? in termini di qualità cosa credi che sia meglio?
DP (che ora si chiamano MacPorts) sono un sistema filosoficamente
ispirato al sistema dei port di BSD. Per ora li compili tutti (ma
visto che di recente Apple ha fornito parecchio hardware al team,
dovrebbero arrivare versioni precompilate).
I ports sono molto piu' aggiornati. fink contiene un sacco di roba
vecchia vecchia (fino a poche settimane fa si era ancora a Ruby 1.8.1,
per capirci). Inoltre fink ha una frazione molto piccola del software
presente sui DarwinPorts. Piccolissima. Il *numero* dei pacchetti e'
poco piu' della meta'. Solo che ogni 'versione' del pacchetto viene
pacchettizzata diversamente. Per esempio per apache ci sono circa 20
pacchetti. Il pacchetto principale, quello di sviluppo, poi vari
moduli. Molti pacchetti poi sono spezzati in tre. pacchetto,
pacchetto-dev e pacchetto-shlib.
Non ho voglia di fare i conti precisi, ma probabilmente i pacchetti di
fink sono meno di un quarto (forse un quinto) di quelli di
MacPorts. Oltre che MacPorts contiene anche alcuni programmi con
interfaccia Aqua (per esempio AquaTerm per dare la GUI a
octave/gnuplot invece che fare disegnare su X11, oppure HandBrake --
encoding video -- e altri di cui non ricordo per nulla il nome -- e
ora sono su linux e non posso guardare l'elenco --).
MacPorts usa il sistema delle varian. Ogni pacchetto ha piu'
'varianti' e l'utente puo' scegliere quelle che vuole, con una
configurazione abbastanza granulare. Se questo non basta, i portfile
sono facilmente modificabili (e uno puo' facilmente cambiarci dentro i
parametri di configure del pacchetto e roba simile, di fatto unendo la
praticita' di un sistema di pacchettizzazione con la potenza delle
compilazioni manuali).
-- 
RiK0

 peccato che questo sia vero per tutti i meccnismi di pacchettizzazione.
Si, per questo l'uso di bundles non crea di questi problemi, non c'e` 
nulla da fare se non una copia. E si spera che un OS riesca a copiare i 
file.


 darwinports.
Dissento su Wierda. Fink installa *TUTTO* in /sw e solo li, mentre gli 
i-installer installano in /usr/local e forse anche da altre parti 
(/usr/XXX?). Darwinports mai usato, e` come fink autocontenuto oppure 
no?


 file.
perň cosě non hai le shared libraryies, se ogni volta devi copiare tutto.
O sbaglio?

 
installa in /opt/local
vedi qua.
http://trac.macosforge.org/projects/macports/wiki/InstallingMacPorts
Certo che se macports ha più pacchetti, mi sa che uso quello.
Oh, piccola domanda scema: apple fornisce un server X. Le librerie di
sviluppo sono normali, compatibili con quelle di linux? La domanda è
scema e credo di sapere già la risposta, però voglio essere sicuro: per
la mia ricerca ho dei visualizzatori scritti per X, non vorrei trovarmi
un braghe di tela....

 un braghe di tela....
Si, e' compatibile.
Puoi installare X da MacPorts comunque.
  ngw


in cosa si differenziano i due server X?

 in cosa si differenziano i due server X?
Credo che quello distribuito da Apple (quello che uso io) abbia delle
estensioni per OSX. Il che non ho idea di che cosa significhi in
soldoni.


 O sbaglio?
Regola d'oro: un OS fornisce (dovrebbe almeno) tutte le shared 
libraries che una terza parte abbisogna per fare un programma. Se non 
vuoi usare QUELLE, sono problemi del programmatore e non di certo 
dell'OS.
Credo che ve ne siano gia` abbastanza di shared libraries per far tutto:
sensei:sensei$ ls /System/Library/Frameworks/
AGL.framework/                  IOBluetoothUI.framework/
Accelerate.framework/           IOKit.framework/
AddressBook.framework/          InstallerPlugins.framework/
AppKit.framework/               InstantMessage.framework/
AppKitScripting.framework/      InterfaceBuilder.framework/
AppleScriptKit.framework/       JavaEmbedding.framework/
AppleShareClient.framework/     JavaVM.framework/
AppleShareClientCore.framework/ Kerberos.framework/
AppleTalk.framework/            Kernel.framework/
ApplicationServices.framework/  LDAP.framework/
AudioToolbox.framework/         Message.framework/
AudioUnit.framework/            OSAKit.framework/
Automator.framework/            OpenAL.framework/
CPlusTest.framework/            OpenGL.framework/
Carbon.framework/               PCSC.framework/
Cocoa.framework/                PreferencePanes.framework/
CoreAudio.framework/            Python.framework/
CoreAudioKit.framework/         QTKit.framework/
CoreData.framework/             Quartz.framework/
CoreFoundation.framework/       QuartzCore.framework/
CoreMIDI.framework/             QuickTime.framework/
CoreMIDIServer.framework/       ScreenSaver.framework/
CoreServices.framework/         Scripting.framework/
DVComponentGlue.framework/      Security.framework/
DVDPlayback.framework/          SecurityFoundation.framework/
DirectoryService.framework/     SecurityInterface.framework/
DiscRecording.framework/        SenTestingKit.framework/
DiscRecordingUI.framework/      SyncServices.framework/
DiskArbitration.framework/      System.framework/
DrawSprocket.framework/         SystemConfiguration.framework/
ExceptionHandling.framework/    TWAIN.framework/
FWAUserLib.framework/           Tcl.framework/
ForceFeedback.framework/        Tk.framework/
Foundation.framework/           WebKit.framework/
GLUT.framework/                 XgridFoundation.framework/
ICADevices.framework/           vecLib.framework/
IOBluetooth.framework/
Se *IO* voglio usare GTK o derivati (tipo AdiumX), non mi duole il 
cuore a compilarla io e metterla nel bundle: potevo usare le altre 
librerie a corredo. L'applicazione e` l'applicazione, l'OS e` l'OS.
PS. Gli smanettoni piu` vigorosi possono anche usare le librerie 
private che sarebbe meglio non usare:
sensei:sensei$ ls /System/Library/PrivateFrameworks/
AFPDefines.framework/                JavaApplicationLauncher.framework/
Admin.framework/                     JavaApplicationLauncherUI.framework/
AirPortConfig.framework/             JavaBrowser.framework/
Apple80211.framework/                JavaCarbonSupport.framework/
AppleAppSupport.framework/           JavaKit.framework/
AppleScript.framework/               JavaScriptGlue.framework/
AppleVA.framework/                   LanguageAnalysisCore.framework/
Assistant.framework/                 LatentSemanticMapping.framework/
BEEP.framework/                      MachineSettings.framework/
BezelServices.framework/             MediaKit.framework/
Bom.framework/                       MonitorPanel.framework/
ByteRangeLocking.framework/          NetInfo.framework/
CALCore.framework/                   NetworkConfig.framework/
Calculate.framework/                 OpenTransport.framework/
ChineseTextConverter.framework/      PSNormalizer.framework/
CommonCandidateWindow.framework/     PasswordServer.framework/
ContentIndex.framework/              ProKit.framework/
DAVKit.framework/                    QuartzFilters.framework/
DMNotification.framework/            SPSupport.framework/
DSObjCWrappers.framework/            ScreenReader.framework/
DVD.framework/                       SearchEngine.framework/
DesktopServicesPriv.framework/       SecurityTokend.framework/
DevToolsBundleInjection.framework/   ServerControl.framework/
DevToolsCore.framework/              SetupAssistant.framework/
DevToolsInterface.framework/         SetupAssistantIA.framework/
DevToolsRemoteClient.framework/      SetupAssistantSupport.framework/
DevToolsSupport.framework/           SherlockCore.framework/
DigiHubPreference.framework/         Slideshow.framework/
DirectoryServiceCore.framework/      SoftwareUpdate.framework/
DiskArbitration.framework@           SpeechDictionary.framework/
DiskImages.framework/                SpeechObjects.framework/
DiskManagement.framework/            SyncLegacy.framework/
DisplayServices.framework/           SyncServicesUI.framework/
DocSetAccess.framework/              Syndication.framework/
DotMacLegacy.framework/              SyndicationUI.framework/
DotMacSyncManager.framework/         SystemMigration.framework/
EAP8021X.framework/                  SystemUIPlugin.framework/
F1SyncCommon.framework/              TimClient.framework/
FileSync.framework/                  TimServer.framework/
GLResourceEditor.framework/          URLAccess.framework/
GraphKit.framework/                  URLMount.framework/
Graphite.framework/                  VSP.framework/
HTMLDisplay.framework/               VideoConference.framework/
HelpUI.framework/                    XDBase.framework/
ICACameraPriv.framework/             XDInterface.framework/
ICANotifications.framework/          XQuery.framework/
ICAScannerPriv.framework/            XgridInterface.framework/
ISSupport.framework/                 ZeroLink.framework/
Install.framework/                   iPod.framework/
International.framework/             iPodSync.framework/
InternetConnect.framework/           vmutils.framework/
IntlPreferences.framework/
(e sono abbastanza...)


 dell'OS.
[cut]
   A me 'sta cosa convince fino ad un certo punto... Ti faccio il _mio_
esempio, che probabilmente non è significativo, ma che esiste...
Io sviluppo una serie di librerie (attualmente sono solo cinque pacchetti)
che, per la loro estrema specificità (si tratta di roba di gestione di dati
sismici) non verranno _MAI_ distribuite da alcun OS.
Su queste librerie sono basati un certo numero di programmi (più o meno
grandi, alcuni da CLI altri da GUI (per la cronaca uso le Qt)) che le
usano. Questi programmi non sono impacchettati tutti in un unico pacchetto
(spesso non avrebbe neppure senso): non si tratta di un'unica suite, ma di
tanti programmi spesso indipendenti.
Seguendo il ragionamento a la OSX, ognuno dei pacchetti dovrebbe portarsi in
bundle tutte le librerie, con la immensa scocciatura, tra le tante cose,
che se correggo qualche bug o faccio qualche miglioria, dovrei reinstallare
tutti i bundle invece di reinstallare solo le librerie...
Mi sarebbe terribilmente scomodo, ma proprio tanto... Quando, invece, io mi
creo cinque deb, faccio dipendere gli altri pacchetti da quei deb e apt-get
mi fa il resto...
Sono d'accordo che le applicazioni non debbano "sporcare" l'OS, ma a tutto
c'e` un limite, IMHO... Probabilmente un buon compromesso potrebbe essere
di installare il resto sotto /opt invece che in /usr, ma l'idea dei bundle
proprio non riesco a farmeli piacere, se non per casi particolari...
Saluti...
-- 
                          | Mi sto arrabbiando...
\|/ ____ \|/   \ ||_|     | ...non vi piacerebbe vedermi
"@'/ ,. \`@"    \|| |     |    arrabbiato...
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |       Dr. David Bruce Banner

 mi fa il resto...
infatti questa mi pare una puttanata.

 infatti questa mi pare una puttanata.
   Illuminami: tu cosa faresti al mio posto ???
-- 
                          | Almeno tu che puoi fuggi via canto
\|/ ____ \|/   \ ||_|     | nomade questa cella e` piena della
"@'/ ,. \`@"    \|| |     | mia disperazione tu che puoi non
/_| \__/ |_\ Vax Headroom | farti prendere.
   \__U_/                 |                    BMS

    Illuminami: tu cosa faresti al mio posto ???
   Mi viene il dubbio di aver preso il c@22o per la banca dell'acqua, come
diciamo dalle mie parti...
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Un corpo immerso in un liquido
"@'/ ,. \`@"    \|| |     |   e` quello di un subacqueo.
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |

 
che in italiano vuol dire? :-)

 che in italiano vuol dire? :-)
   Aver preso fischi per fiaschi: non avevo capito la tua risposta, chiedo
venia...
-- 
                          |   L'ultima volta che ho fatto
\|/ ____ \|/   \ ||_|     |   sesso ???
"@'/ ,. \`@"    \|| |     |   Era notte, era buio,
/_| \__/ |_\ Vax Headroom |   ero solo...
   \__U_/                 |                 Daniele Luttazzi

 no?
Si, open darwin e' autocontenuto. E funziona.
-- 
RiK0

 proprio non riesco a farmeli piacere, se non per casi particolari...
La questione e` semplice. Se tu perdessi anche 200 MB, sarebbe comunque 
una percentuale *IRRISORIA* di spazio su un HD da 20 GB che *OGGI* e` 
considerato una merda perche` troppo piccolo.
Guadagni moltissimo in facilita` per l'utente che occupa con film ed 
mp3 lo spazio, non con le librerie.


 Si, open darwin e' autocontenuto. E funziona.
Ottimo, se e` meglio di fink, dopo la tesi di disoccupato di ricerca lo metto.


 mp3 lo spazio, non con le librerie.
   Ripeto, non ho mai parlato di spazio su disco...
Lo so, la mia è un'applicazione abbastanza particolare, ma non credo di
essere proprio l'unico sulla faccia della Terra ;-)...
Saluti...
-- 
                          | universi dissidenti, 
\|/ ____ \|/   \ ||_|     | ognuno con legislazione
"@'/ ,. \`@"    \|| |     | fisica autonoma.


 Domanda semplice: *QUANTO* sprechi in proporzione di spazio su disco?
il problema non è lo spazio, il problema è stare dietro con bugfix e
simili. Se c'è un baco in gtk, preferisci aggiornare gtk o tutte le
applicazioni?
(nota bene, ho detto gtk perché è la prima che mi è venuta in mente,poi
magari non si applica....)

 Ottimo, se e` meglio di fink, dopo la tesi di disoccupato di ricerca lo metto.
A mio modesto parere lo e', senza nessuna intenzione di flame. Se non
altro la maggiore disponibilita' di software (oltre che la
flessibilita' di avere cose installate ma non attive, permettendo
facilmente piu' versioni dello stesso programma) me lo fanno
preferire.
-- 
Rik0

 magari non si applica....)
Preferisco, esempio banale, che AdiumX mi dica che c'e` una versione 
nuova perche` lei usa le GTK 100.2.3.5-sub45.6 mentre il ToolGTK-AquaX 
usa 100.2.3.5-sub45.4 (cambia .4) che non e` afflitto dal bug.
Per me programmatore? Non cambia nulla visto che devo ricompilare per 
essere sicuro che funzioni.
Oppure tu in produzione ti fidi che tutto funzioni senza ricompilare 
mai nulla? Io no.


 essere proprio l'unico sulla faccia della Terra ;-)...
Beh no, ma ti faccio la stessa domanda che ho fatto ad Ottavio. Ti fidi 
di aggiornare in produzione le librerie (non sviluppate da te, chiaro) 
senza mai ricompilare i programmi che la usano? Perche` io no, ci sono 
rimasto scottato piu` volte (mzscheme come esempio).


 nulla? Io no.
con debian stable? la seconda che hai detto.

 rimasto scottato piu` volte (mzscheme come esempio).
   E' chiaro che non le installo *direttamente* in produzione... Prima le
provo sui muletti (pensa faccio questo anche per la roba che scrivo io ;)),
se vanno le mando in produzione. Negli ultimi tre anni non è mai stato
necessario ricompilare i programmi se non nei casi di cambio di API (una
volta su una libreria, un'altra volta su un'altra libreria)...
Sarò stato particolarmente fortunato, che te devo di'...
Saluti
[1] - Che poi, alla fine, altro non sono che dei PC con un fattore di forma
più piccolo ed un processore "poco potente": la scelta di metterci la flash
invece del disco è stata nostra ed è stata dovuta solo a problemi di
consumi maggiori della versione con HD...
-- 
                          |
\|/ ____ \|/   \ ||_|     | ...fascisti su Marte,
"@'/ ,. \`@"    \|| |     | rosso pianeta bolscevico
/_| \__/ |_\ Vax Headroom | e traditor...
   \__U_/                 |


cosa vuol dire "installate ma non attive"? so che è una domanda scema,
ma mi sto avvicinando adesso a questo mondo....

 ma mi sto avvicinando adesso a questo mondo....
E' una terminologia di darwin ports. Un pacchetto e' installato
significa che e' compilato e tutto. Ma per esempio non ha link
simbolici che puntano a se stesso (che so... puoi avere installati
emacs21 e emacs22, poi quando ne attivi uno dei due, emacs punta a
quello). In parte e' simile al concetto di alternatives di apt.
Solo che e' all'interno dello stesso pacchetto. Oppure puoi avere piu'
versioni di un software installate (tante a piacere) o di una
libreria, e attivare solo l'ultima. Ma vecchi software compilati
contro le precedenti continuerebbero a funzionare.
Allo stesso modo puoi avere piu' versioni dello stesso sw compilate
con diverse opzioni tutte insieme, e attivarne una per volta.
-- 
Rik0

 consumi maggiori della versione con HD...
Interessante. Per cosa lo usate?




A me ha sfanculato samba server (sui server uso solo debian stable), ed 
ho mazziato quello che lavora con me per ``far update senza ritegno''. 
Non mi fido manco di mia madre...



No, il sistema operativo sa sempre quello che sta facendo. E' la tua
applicazione di setup che deve credere di avere installato il file e
proseguire.
Perchè:
a) se si ferma, tu il programma non lo hai installato e non lo usi
b) se non si ferma, ma gli dai i privilegi di root e gli dici: fai in /lib 
quello
che cacchio ti pare, (stile Unix), lei ti sovrascrive le librerie del core 
del tuo
sistema (che sono customizzate e specifiche per il sistema), con
quelle di un'altra distribuzione (perchè sono più recenti..... ci hanno
il subversion di secondo livello maggiore no?) ed il sistema si
impalla.
Invece, se il sistema operativo illude il setup che la libreria nr. 3 sia
stata installata, quando invece non è vero, tu avrai su disco la
libreria nr. 1, nr. 2, nr. 4, nr. 5, nr. 6.... e per la nr. 3 il sistema
caricherà la fake library specifica per la tua distribuzione.

 Interessante. Per cosa lo usate?
   Due diverse applicazioni: uno lo stiamo usando come acquisitore di un
array sismico a 16*3 canali, 24 bit/sample, 50 sample/s che parla con il PC
tramite la parallela usata in modo *estremamente* non standard. All'inizio
l'array era stato pensato per essere trasportabile ed acquisire in locale
sul PC: il software originale era tutto per windows. In seguito abbiamo
pensato di trasformarlo in un sistema stabile in acquisizione permanente
remota: l'alimentazione rigorosamente a batterie+pannelli solari rendeva
abbastanza complicato usare un PC "vero". Ci siamo quindi messi a
riscrivere tutto il software per linux e comprimere il tutto su una flash.
Questo perché lo spunto del motore dell'HD, per quanto piccolo, causava dei
fastidiosi transienti sugli ADC (le schede di acquisizione non sono, ahimé,
di grande qualità)...
Il secondo, con HD, si trova in un posto con la 220 (quindi chi se ne frega
dei consumi) ma con poco spazio (una scatola di derivazione, praticamente).
Ci fa da ponte wireless-seriale perché in quel punto non siamo riusciti a
tirar su un collegamento wifi causa *ENORME* inquinamento elettromagnetico:
praticamente la 2.4GHz era completamente saturata dai ponti delle radio e
delle TV che hanno i ripetitori da quelle parti...
E' un coso un po' meno potente di questo (è già fuori produzione):
http://www.lippert-at.com/index.php?id=344
La prossima frontiera sarà di mettere Sarge su aggeggi del genere:
http://www.soekris.com/net4826.htm
in modo da usare le due slot minipci per montarci due schede wifi e
trasformarlo in un router wireless/wireless (attualmente usiamo una coppia
di AP linksys per fare 'sta cosa, ma consumano un po' troppo e non sono
abbastanza flessibili)...
Saluti
-- 
                          |   
\|/ ____ \|/   \ ||_|     |   Sono aperte le gare di lancio del
"@'/ ,. \`@"    \|| |     |   cavalletto...
/_| \__/ |_\ Vax Headroom |   ISCRIVETEVI NUMEROSI !
   \__U_/                 |

 Non mi fido manco di mia madre...
ti dirò, a me non è mai usccesso. E ti assicuro che uso samba in modo
massicco con pdc, bdc, fileserver membri di dominio e compagnia bella.

 ora. 
che perla! Adesso unix ha copiato i file ini di M$? Ma per piacere, ma
vai a studiare... guarda le release dei vari software e scopri chi è
venuto fuori prima.
Ma vergognati, pretendi di insegnare quando non sai nulla!
Ma fatti una cultura prima di parlare.
Scommetto che la prossima cosa che dirai è che more del dos è stato
copiato da unix vero? e che molti dei flag dei comandi del dos sono
stati copiati dai comandi unix cambiando / con -?
Patetico.


Scusa: io parlo di ***mentalità****. Che cazzo c'entra con "copiare i file
.INI" te lo sai solo tu.
L'idea alla base di Unix e dei file .INI di Microsoft (non me ne frega 
niente
se Unix risale a 20 anni prima e Microsoft a 20 anni dopo), è sempre la
stessa identica: ****NON***** deve essere il sistema operativo a
fornire delle funzionalità per consentire la memorizzazione dei file di
configurazione del programma. Quindi, ogni programma si scriva i propri
file di configurazione nel formato che meglio ritiene opportuno, usando
le normali routine di accesso al file system del sistema operativo, ed
al di fuori di qualsiasi controllo da parte del sistema operativo.
Poi, siccome il programma deve anche registrare dei componenti, il
programma si apra con una bella fopen un file di testo in /etc e
se lo modifichi (se l'os è multiuser dopo che l'admin ha dato i permessi,
ovviamente....)
Questo, guarda che coincidenza, è proprio ciò che fanno i programmi Unix.
E che fanno i programmi Windows 3.x. Ma questo non significa che
unix ha copiato i file .INI di M$, sta cosa l'hai letta sul tuo monitor
molto ma molto sfasciato, perchè non c'era modo di capirla in quel
modo manco volendo distorcere il senso della mia frase fino a
capovolgerlo.
E' ***l'idea*** che è la stessa, ed è anche logico che sia così: le prime 
versioni
di unix e, anni dopo, Windows 3.x sono stati creati quando la potenza di
calcolo/memoria dell'elaboratore erano limitate, quindi l'inserire 
funzionalità
integrate nell'os per gestire l'installazione/disinstallazione quando era 
sufficiente
una bella fopen da parte di chi scriveva il setup era considerato un'inutile
spreco di risorse.
E' solo con Windows 95 che ci si pone il problema, e compare un API per
l'accesso al registro a disposizione dei programmatori.
Su Linux hanno continuato nella vecchia tradizione Unix, e solo ora qualcuno
si sta accorgendo che un API apposita è meglio averla (Elektra, GConf),
peccato che sono progetti che non influiscono che in modo marginale
sulle attuali distribuzioni.
Chiaro ora il mio pensiero?

 Chiaro ora il mio pensiero?
sì, caga fuori il codice di nanodesktop, altrimenti sei solo un coglione
che parla a vuoto. Perché con quello che hai scirtto non c'è sistema
operativo che ti va bene. E visto che non ti riesci nemmeno a
qualificare come programmatore che voce in capitolo vuoi avere?

 qualificare come programmatore che voce in capitolo vuoi avere?
No, per ora no... non mi va.....

 No, per ora no... non mi va.....
come volevasi dimostrare.

 come volevasi dimostrare.
Vedo che è un pò di tempo che non vai su Google.....

 Vedo che è un pò di tempo che non vai su Google.....
mi dici dove trovo i sorgenti al sito
http://visilab.unime.it/~filippo/
no perché su google trovo solo annunci di quello che uscirà.

 no perché su google trovo solo annunci di quello che uscirà.
Non li trovi perchè per ora non è mia intenzione rilasciarli (sto lavorando
sulla NanoM proprio in questo momento).
Certo è strano che ora ci sia qualche migliaio di persone che aspetta
Nanodesktop, c'è qualche centinaio di persone che ha provato le
Nanodesktop Apps, c'è una forte pressione da parte delle varie
comunità PSP per sapere quando rilascerò, ricevo mail praticamente
ogni giorno, c'è un entusiasmo che è praticamente
alle stelle ovunque, e poi io non so programmare....
Sì vede che le Nanodesktop application si sono scritte da sole, che te
devo dì....
:))))))))
Ciao

 devo dě....
o che sono tarocche.

 o che sono tarocche.
Ossia?
Vediamo un pň: come avrei ottenuto le famigerate applicazioni?
(voglio vedere ora come te ne esci....)

 (voglio vedere ora come te ne esci....)
usando il toolkit sony? non sono un esperto di psp, peň tu stesso hai
detto che esiste un toolkit di sony.

 detto che esiste un toolkit di sony.
Che costa qualche decina di migliaia di euro.....
Strano poi che ci sia un laboratorio di ricerca universitario che mi dà
tutto questo supporto, se poi io sto usando il toolkit di Sony;
Strano poi che non ci sia mezza applicazione per PSP che abbia uno
stile grafico simile a quello di Nanodesktop.....
Il codice sorgente di Nanodesktop esiste, mettiti il cuore in pace....
del resto anche il codice di Windows so che è chiuso, ma nessuno
ha mai dubitato della sua esistenza, almeno finora....

 ha mai dubitato della sua esistenza, almeno finora....
forse perché non ci sono solo demo del cazzo ma c'è pure il sorgente?

 forse perché non ci sono solo demo del cazzo ma c'è pure il sorgente?
Vediamo di ragionare un attimo, vuoi?
Dunque, se io ho scritto delle demo, significa che deve esistere da qualche
parte il codice della libreria.....
Tra parentesi, ci sono dei forum che mi stanno dando un pò di feedback
utente e nel giro di 24 ore ho rilasciato due nuove versioni delle 
Nanodesktop
Apps, che recepivano i vari suggerimenti che mi hanno dato.
Se non sapessi programmare, come dici tu, non avrei nemmeno potuto
modificare le demo tarocche. Demo tarocche che invece sono state
modificate.
Qualcosa non quadra, o no?

 Qualcosa non quadra, o no?
tu? ;-)


Non hai capito. Io sostengo semplicemente che se si vuole fare astrazione,
la soluzione migliore e più elegante è un bel setup.exe (nota il .exe) che
usi una libreria per comunicare con un demone che gira in background.
E non sono l'unico sul pianeta: conosco una società americana che ci
ha fatto i soldi su questi concetti elementari, ed attualmente il suo os ha
il 98% del mercato.... Tutti scemi?
Sì, ok, tu dici: possiamo fare astrazione con gli script, con configure,
automake, ecc. ecc. Ed a me sembra una soluzione poco elegante ed
inefficiente. Tutto qua.

 inefficiente. Tutto qua.
la società in questione non ha fatto i soldi per setup.exe....
Quello che mi fa girare le balle è che tutto quello che dici c'è già
sotto unix. Il problema si èposto 20 anni fa e gli autotools sono stata
la soluzione. Vecchi? sì. Obsoleti? direi di no, il loro lavoro lo
fanno, sempre con lo stile unix dove non hai un blocco di codice che fa
tutto ma nati piccoli programmini.
Sull'inefficiente hai preso una cantonata, perché si fanno delle cose
molto interessanti.
Sul non elegante... Bah...Ti posso concedere che è software vecchio, ma
proprio per questo ha la sua maturità. Altrimenti sarebbe morto da tempo.

 proprio per questo ha la sua maturità. Altrimenti sarebbe morto da tempo.
Ok, facciamo un altro giochetto allora.....
Dunque, 2 giorni fa ho scaricato il psptoolchain. Provalo.
Usalo sotto Linux o con Cygwin. Io l'ho usato con Cygwin.
Modifica lo script per fare in modo che scarichi via svn le ultime
patch, ma non esegua la compilazione. Poi vai in
G:\Cygwin\tmp\pspdev\newlib-1.13.0\newlib\
ed apriti lo script configure. Bene, ad un certo punto del codice
tu trovi questo pezzo:
-disable-* | --disable-*)
    ac_feature=`echo $ac_option|sed -e 's/-*disable-//'`
    # Reject names that are not valid shell variable names.
    if test -n "`echo $ac_feature| sed 's/[-a-zA-Z0-9_]//g'`"; then
      { echo "configure: error: $ac_feature: invalid feature name" 1>&2; 
exit 1; }
Ora, parliamo di efficienza. Per verificare che non ci sono caratteri
errati, il parser deve richiamare il programma echo, eseguire una
pipe su sed, poi richiamare il programma test ed inoltre le variabili
non sono degli indirizzi in memoria, ma sono delle variabili di
ambiente che vengono fornite da un interazione bash/script.
Quanto overhead c'è lì dentro rispetto ad una semplice funzione
C che viene compilata? Quale codice è più leggibile?
Parliamo di robustezza. Ho perso 2 giorni perchè lo script non funzionava:
mi dava invalid feature: --enable-install-bfd che è del tutto assurdo. Ma
l'altra volta funzionava, quindi all'inizio pensavo che fosse qualche cosa
legata all'aggiornamento delle utility cygwin. Vado in rete, e trovo che
altre persone hanno avuto lo stesso problema.
Ad un certo punto, dopo 2 giorni di imprecazioni, mi viene l'idea: proviamo
a reinstallare le cygwin senza abilitare l'opzione che impone la conversione
CR/LF. Bene, si è messo a funzionare.
Naturalmente le ultime 2 righe (e la considerazione di cui sopra) spiegano
bene perchè MS fa i soldi. Nel mondo civile i confronti stringa li fa un
pezzo di codice C e non la bash o make.

 altre persone hanno avuto lo stesso problema.
o forse perché hai tirato giù delle patch via svn per avere una release
non stabie? Dai, l'hai detto tu stesso che l'hai patchato e prima andava...

 non stabie? Dai, l'hai detto tu stesso che l'hai patchato e prima andava...
AVETE SCASSATO IL CAZZO CON QUESTO THREAD E IMPARATE A QUOTARE LATRINE
DI MERDA

 andava...
No, и un pochino diverso il discorso.
Se fosse stato come dici tu non avrebbe funzionato neanche dopo che ho
tolto da Cygwin l'opzione di conversione CR/LF.
No, il problema и che con quell'opzione tutti gli LF in un file vengono
tradotti automaticamente in CR. Ivi comprese le stringhe degli script.
Ora, per una qualche ragione che non capisco, ad un certo punto la
variabile di ambiente ac_option finiva per contenere una stringa che
terminava con LF. Questa veniva convertita da Cygwin in CR, e
poi passata ad un parte dello script simile a quello che ti ho riportato,
che doveva verificare se c'erano caratteri non validi. Siccome ora
c'era il CR, lo script si interrompeva con un errore.
Ciao
Pegasus

 tolto da Cygwin l'opzione di conversione CR/LF.
falso. dipende da dome scrivi il tutto. Per inciso,quello che tu citi è
un errore come, che scappa. e che con una rc viene beccato subito.

 un errore come, che scappa. e che con una rc viene beccato subito.
Intanto a chi ha scritto psptoolchain è sfuggito.....

 Intanto a chi ha scritto psptoolchain è sfuggito.....
hai tirato giù da svn. Comunque ti ripeto, capita spesso.


Infatti mi hanno fatto notare delle possibili migliorie in MouseControl e 
nel
giro di 48 ore ho implementato le modifiche richieste.
Ma non sono disposto ad accettare, è proprio una mia questione personale,
un semplice "cazziamento" senza alcun contributo.
E' molto facile cazziare il lavoro altrui senza metterci le mani.

 }
char* strchr(const char *s, int c);
(ISO C)
E se vuoi un parser per far qualcosa di meglio, bison, lex, e yacc. Fai 
molto prima.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 E' molto facile cazziare il lavoro altrui senza metterci le mani.
LOL. Tu č da quando sei qui che non fai che sparare sul lavoro altrui
senza metterci le mani...
-- 
In a minute there is time for decisions and revisions which a minute
will reverse
T.S. Eliot

 senza metterci le mani...
mi hai rubato le parole di bocca!

 mi hai rubato le parole di bocca!
con l'unica piccolissima differenza che dietro al kernel Linux
ci sono.... quanti sviluppatori? quanti anni di sviluppo?
ma č una differenza trascurabile, per il resto č la stessa identica
situazione, uguale uguale eh.....

 ci sono.... quanti sviluppatori? quanti anni di sviluppo?
1) cosa centra? Tu comunque critichi il lavoro aoltri senza contribuire.
2) gli autotools non sono fatti mica dal team del kernel (tra parentesi,
il kernel non fa uso degli autotools, per via di come è compilabile)

 il kernel non fa uso degli autotools, per via di come è compilabile)
Chi ha detto il contrario?

 e che ha la complessità di Nanodesktop.
quanto vai avanti ad arrampicarti sugli specchi?

 ha scritto nel messaggio
news:4568c...@x-privat.org...

Non è questione di arrampicarsi sugli specchi: è questione di
buon senso (che come al solito tu non sembri avere).
Quando uno ha a disposizione un team di 50-100-200 persone
per creare un programma complesso, fa delle scelte precise:
per esempio, ci sono due tizi nel team che si occupano della
code-review, che si guardano il codice e lo scrivono in modo
pulito.
Quando uno il super-team non ce l'ha, ed in più ha un programma
così complesso da scrivere da zero, allora fa delle scelte differenti:
si cerca di scrivere del codice pulito, ci si prova, ma se di tanto
in tanto scappa un bel
if (a==1)
{
    XWindowRender (WndHandler);
}
else
{
    b==5;
}
pazienza, basta che funzioni. Magari poi in un secondo tempo uno toglierà
quelle parentesi perchè ininfluenti (è solo un esempio, beninteso....).
Poi, le critiche che io faccio a cose come Linux, o come X, sono critiche
**strutturali**, io non mi metto a controllare se hanno messo o meno gli
extern dei file .h delle librerie xlib, o se hanno usato le lettere 
maiuscole
per indicare il nome di una struct.
Ultimo piccolo problema: cose come X-Window o Linux sono on-the-road,
sono software che hanno anni di sviluppo alle spalle, che hanno raggiunto
una certa maturità. Nanodesktop ha solo qualche mese di sviluppo alle
spalle, non ha senso giudicarlo con i medesimi criteri.
Il migliaio di persone che fanno pressione per averlo, hanno accettato che
alla prima alpha la libreria sia rigorosamente monothread e che sia senza
accelerazione hardware. Perchè? Perchè sapevano che con le risorse che
io ho attualmente a disposizione più di questo non posso fare: sanno che
per come è strutturato Nanodesktop, sarà facile in un secondo momento
portare l'accelerazione hardware, il supporto per il processore matriciale
ecc. ecc. Per ora si tratta solo di creare un programma fortemente 
strutturato,
facilmente portabile e facilmente estensibile, creando il minimo di 
funzionalità
indispensabili per poterlo usare in un'applicazione.
Quando Nanodesktop avrà un paio di anni di sviluppo alle spalle, con una
bella comunità dietro, allora potremo confrontarlo con eventuali altri 
programmi
dello stesso tipo, ma non ora.
Altrimenti ti prendo Linux 1.0 e te lo confronto con le caratteristiche dei 
kernel
BSD presenti al tempo, e vediamo che figura ci fa.....
Saluti
Pegasus


Errata corrige. b=5.

 BSD presenti al tempo, e vediamo che figura ci fa.....
c.v.d., non hai capito un cazzo.

 è una merda. Basta vedere la tua idea di installer....
Beh, spero che non vorrai applicare la logica Unix dei tanti piccoli 
programmini
che fanno tante cosine distinte alla PSP, perchè la cosa sarebbe un 
tantinello
improponibile (... ma solo un pochino eh...).
Riguardo alla mia idea di installer: la mia idea di installer è quella 
condivisa da
mezzo migliaio di società, che usano setup.exe che contengono internamente
il codice per distribuire i loro applicativi. Condivisa anche da Redmond che
addirittura ora impone di usare MSI (e quindi setup.exe che si comportino
come pacchetti autocontenuti), per dare la certificazione designed for
Windows ad un programma commerciale.

 Windows ad un programma commerciale.
guarda, posso citarti un disastro di programmi che se ne fregano di tale
certificazione.

 certificazione.
Ed io posso citarti un altro disastro di programmi che invece fanno così:
da Firefox ad OpenOffice, tu hai sempre il tuo .exe che contiene l'archivio
compresso + il codice per l'interfaccia con le opzioni di installazione
rigorosamente GUI-based + il codice per installazione e configurazione
primo avvio.
Make install non esiste nel mondo Windows, fattene una ragione.

 che mi aiutino.... non ti sembra di renderti un pò ridicolo?
vuoi che contatto il tuo prof?

ehm... tutto quello che viene con cygwin non esiste?

>> Sì può dire sul mio lavoro quello che si vuole, quello che non mi piace è

ehm... tutto quello che viene con cygwin non esiste?

 ehm... tutto quello che viene con cygwin non esiste?
Vabbè dai.... quale percentuale di codice Windows è? Il 5%?
. 

 di Mb di roba.... Insomma, non posso postare il codice su un NG.
sai che l'adsl c'è quasi dappertutto?
quale sarà la prossima scusa?

 quale sarà la prossima scusa?
Nessuna.
Io sono il creatore del progetto Nanodesktop, ed io decido quando
rilasciare il codice.... It's simple.
Io non ho obblighi di rilascio: se io decido che non è ancora il momento
perchè voglio sistemare delle cose prima, io non rilascio.
Avrei rilasciato a gente che mi vuole aiutare a scrivere codice, non a
gente che vuole solo "giudicarmi" il codice.
Naturalmente tu sei liberissimo di credere che Nanodesktop sia una
bufala, anche se ancora non ho visto una ricostruzione credibile di
come sarei riuscito a creare le 12 applicazioni che sono disponibili,
di come avrei ottenuto i video, di come mai non esistono porting
delle librerie OpenCV di Intel per PSP in giro (forse avrò copiato
il codice binario da un medium visto che su Internet non c'è nulla
di simile), di come mai i programmatori PSP che hanno visto il
lavoro, e che conoscono tutti gli homebrew che sono attualmente
disponibili per PSP, non hanno riconosciuto il codice copiato da
tizio e caio, ed invece sono **tutti** impazziti con giudizi che vanno
dallo "straordinario" allo "stupefacente", di come faccio a rilasciare
ogni settimana patches che includono le modifiche che mi hanno
richiesto (boh, forse modifico i binari), di come mai le applicazioni
Nanodesktop girano sull'emulatore PSPE e su PSP, quando è noto
che l'emulatore PSPE non fa girare gli homebrew per PSP.
E, last but not the least, strano che il Visilab mi dia un hosting di un
sito Internet, cosa che non è che capiti spesso in Università.
Ma non preoccuparti, guarda: Nanodesktop è una bufala e gli applicativi
sono fatti con Powerpoint. Contento?
Ciao
Pegasus

 rilasciare il codice.... It's simple.
vedo che hai già driblato la parte tecnica... questo la dice lunga.
Per arrivare alla fine del discorso: rilascia quando vuoi, ma non
scassare le balle sul lavoro altrui.
Gli autotools, sebbene a te ignoti esistono, sono sotto gli occhi di
tutti e funzionano.

 tutti e funzionano.
Ho detto "non funzionano"? La finisci di partire sempre per la tangente
e mettermi in bocca cosa che non stanno in piedi?
Ho detto che sono un modo vecchio ed inefficiente di gestire le 
installazioni,
e vedi che non me lo sono inventato io, concordano i programmatori di
Windows, quelli di SkyOS, quelli di PC-BSD.
E, tu che la parte tecnica non la salti, ancora non mi hai spiegato come
può essere più efficiente un codice che sfrutta un megascript per
eseguire l'installazione, rispetto ad un programma C che invece
di richiamarsi un eseguibile per verificare una condizione su
una stringa, si richiama una cretinissima funzione C nel proprio
spazio di indirizzamento.

 spazio di indirizzamento.
quel poco che perdi nell'eseguire lo script lo guadagni in facilità di
manutenzione della struttura.
Inoltre gli script sono crossplatform perché interpretati, il binario C
no. Quindi è anche per questo motivo che gli autotools non sono binari.

 no. Quindi è anche per questo motivo che gli autotools non sono binari.
A parte il particolare che questo c'entra con l'efficienza come
i cavoli a merenda, ti informo che se tu devi distribuire due pacchetti,
uno per x86 e l'altro per MIPS, sarai costretto a distribuire due versioni
del pacchetto, due versioni del programma, e due versioni di tutte le
librerie associate al programma. A quel punto, tantovale che ti fai due
differenti setup.exe (ovvero, facendo l'equivalente Unix, due differenti
ELF di setup) e risolvi subito.
Oppure, se chi scrive l'OS è furbo, ti implementi una soluzione alla
Java con bytecode + virtual machine, che sempre 30 volte più veloce
ed efficiente dello script bash ti rimane.....

 che comprano, non se li sviluppano da zero.
allora non sei scemo, sei solo analfabeta. Posti in un ng che non
capisci. E quello che scrivi nei post spesso non lo capisci e spari cagate.