Newsgroup: it.comp.os.dibattiti
Titolo: [lungo] Makefile == archeologia?

Ciao a tutti,
penso che questo sia il posto giusto dove postare un argomento
che riguarda tutti i sistemi operativi.
Come sicuramente voi sapete, moltissimi software vengono distribuiti
unicamente via sorgente e al fine di facilitare la compilazione vengono
effettuati script di adattamento al sistema corrente (script configure)
che creano il Makefile (a meno che non fosse gia' presente).
Bene, chiunque ha una riga di comando puo' fare poche operazioni
e avere presto un eseguibile pronto per l'installazione, in linea teorica.
Per fortuna, per l'installazione abbiamo checkinstall che e' un enorme
passo in avanti.
In realta' le cose sono molto piu' complesse, questi i problemi:
1) ci sono dipendenze che devono essere risolte manualmente
2) focalizziamo l'attenzione sugli utenti normali: ovviamente e'
impensabile per loro utilizzare la riga di comando (siamo nell'era del
punta-e-clicca, dopotutto).
Naturalmente possiamo argomentare quanto vogliamo sul fatto che le case
produttrici di distribuzioni creano dei pacchetti compilati e reperibili
in maniera estremamente comoda, ma posso testimoniare che molti software
rimangono in sorgente.
Qualcosa non quadra: ci sono troppi intermediari dal programmatore al
fruitore, e dato che il software rilasciato sotto forma di sorgente e'
tantissimo, e' assurdo pensare che ogni distro rilascia tutti i pacchetti.
In effetti, se ci pensiamo un attimo, chi cerca un qualsiasi programma su
internet, nella sua home page si trovera' nella maggior parte dei
casi, nella situazione di scaricare un pacchetto sorgente, probabilmente
senza neppure avere coscienza di *cosa* sta scaricando, e si trovera'
nell'impossibilita' di utilizzo di tale programma.
Possibile soluzione: la realizzazione di un front-end grafico per
l'installazione dei pacchetti sorgenti (solitamente identificabili tramite
estensione tar.gz o tar.bz2), ma c'e' un grosso problema: i cosiddetti
Makefile non sono altro che insiemi di istruzioni che vengono mandate alla
riga di comando, NON insiemi di *dati* che descrivono dipendenze, i file
da compilare ecc. e lo stessa segnalazione di errori non e' in un formato
su cui e' possibile effettuare un semplice parsing (e' solitamente in
lingua inglese).
Quindi si puo' tranquillamente affermare, che non esiste ancora una
maniera standard di ovviare a questa problematica.
D'altronde il Makefile soffre di problemi di vecchiaia: esiste dagli anni
'70 e ormai e' una matassa di workaround (se prendiamo in considerazione i
diffusissimi autotools).
Un idea sarebbe quella di creare un "Datafile" basandosi sull'analisi dei
file degli autotools (Makefile.am e 
configure.in
), anche se spesso,
purtroppo non sono presenti.
E' il caso di mandare il Makefile in pensione? Ma soprattutto: il
"Datafile" e' veramente una cosa fattibile? E quale "ente" dovrebbe
attribuirsene la responsabilita'? Come fare a incentivarne una diffusione
capillare?
Grazie,
-Francesco

 Can't find GTK+ library. Have you installed gtk+ developement packages?
Hai perfettamente ragione. Vedo che sicuramente hai piu' conoscenze di
me nel settore. Sia santificato il configure, ma con un po' di sforzo
possiamo arrivare a livelli di astrazione maggiori. Perche' nessuno ci ha
pensato? Il futuro non stara' nel leggersi README e INSTALL, ma
IMHO, la macchina avra' questo compito. Creare un pacchetto per ogni
distribuzione esistente non e' la soluzione del problema. Sotto questo (e
solo sotto questo) punto di vista Bill Gates ha ragione quando dice che la
realta' del software Open Source e' molto frammentata. Non sto dicendo che
ci vorrebbe un installer grafico per ogni pacchetto sorgente, fossi matto!
Quello che voglio dire e' che ci vorrebbe un installer installato nel
sistema che dal pacchetto sorgente crea e installa il pacchetto per la tua
distro preferita, che sia Debian, Redflag, Ostrogotux o quant'altro.
concludendo: io voglio sperare in GNU/linux per le masse, ma i pacchetti
sorgente vanno "modernizzati" IMHO.
Mio nonno dovra' usare linux. ;^)
ciao,
-Francesco

 Mio nonno dovra' usare linux. ;^)
Passerà del tempo, ma potrà. Abbi fiducia.



Tutto molto bello.
Peccato che in un sistema operativo per le masse del make
all'utente non gliene dovrebbe fregare di meno.
In realtà, non ci vuole niente a cambiare il formato di make,
in modo da farlo diventare un file di dati e non un file di
testo. Che ci vuole? Un formato simile allo .ZIP in cui
esiste un'area per il descrittore (il tuo vecchio make),
ed un'area per i sorgenti.
Un doppio clic sul pacchetto, ed il sistema si mette a
compilare (barra di avanzamento sullo schermo),
scaricando automaticamente da internet i pacchetti
precompilati da una rete peer to peer. Se questi non
sono disponibili per una macchina con le mie stesse
caratteristiche, allora vengono scaricati i sorgenti
delle librerie e compilati al volo insieme al codice del
programma.
No, non è che non si può fare. E' che nessuno finora
lo ha voluto fare, perchè sotto Linux il rispetto per
gli utenti è una farsa. Linux porta tecnologie obsolete,
e se le tiene dietro costi quel che costi, magari
coprendole con front-end ed altre schifezze che
non fanno altro che diminuirne l'efficienza. Questa
è la verità. Quindi MAKE è obsoleto, facciamocene
una ragione.
Saluti
Vegeta

 capillare?
Mai provato Gentoo Linux? Il comando principale per l'installazione del
software è emerge: scarica, configura, compila ed installa i pacchetti
partendo dai sorgenti, e risolvendo le dipendenze, senza che l'utente
debba fare altro che scrivere :
emerge nome-pacchetto
ed aspettare.
Raffaele
-- 
Strategic Blog: 
http://strategic-game.blogspot.com/
Strategic Sourceforge Homepage: 
http://strategic.sourceforge.net/
Strategic Sourceforge Project: 
http://sourceforge.net/projects/strategic/

 una ragione.
Cosa c'è di obsoleto nel makefile?
1. dillo alla MS perchè anche lei lo usa
2. dillo agli sviluppatori che sanno cosa è make
3. studia che è meglio: non sai a cosa serve make o i sorgenti
Vegeta, parli sempre dell'OS-risolvo-i-problemi, ma cadi sulle 
stupidaggini come astrazioni, make, compilazioni...
I sorgenti sono per chi capisce COSA sono. Questo è un dato di fatto.


 Mio nonno dovra' usare linux. ;^)
Probabilmente no. Nessuno obbliga tuo nonno a usare linux. Che usi cio`
con cui si trova bene.
Qua tutti dicono che MacOSX e` figo e facile... Io dico: sticazzi.
E` una settimana che uso MacOSX ormai sul mio nuovo ibook.
Ci ho messo _2_ giorni solo per ottenere un layout di tastiera come lo
volevo io perche` quello americano di default aveva i tasti posizionati
male, per cambiarlo ho dovuto modificare i layout standard a mano,
modificando attributi di un tag xml senza sapere perche` li stavo
modificando in quel modo, scoprendo poi che cosi` facendo 'trasformavo'
il layout della tastiera da tipo unicode a tipo roman, perche`, chi sa
per quale strana ragione, macosx necessita di avere almeno un layout
roman tra i layout selezionati.
Ovviamente dopo che li ho modificati non e` bastato uscire e rientrare
nel mio account... No... perche` ormai il file 'sbagliato' era stato
caricato, ho dovuto cambiare nome al file e uscire ed entrare, perche`
qualche cretino si e` dimenticato che dovrebbe controllare gli mtime dei
file e non solo il nome.
Senza contare che non sembra esistere un modo per avere lo sloppy focus.
Senza contare che il desktop manager per desktop multipli soffre della
scomodita` di avere N finestre e non poter ciclare nelle finestre aperte
della stessa applicazione, oltre che di non sapere dove cacchio sta la
finestra che hai cliccato ecc ecc ecc
Ma nonostante tutto questo, il OSX e` comunque un buon sistema
operativo, certo... Devo scaricarmi 11MB di pacchetto per un upgrade da
8.0.2 a 8.0.3 di BBEdit ma pazienza... 
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.6
Blog: 
http://vvolonghi.blogspot.com
http://developer.berlios.de/projects/weever

 lingua inglese).
Tu ovviamente non conosci il port system di FreeBSD, OpenBSD, netBSD,
darwinports ecc. ecc. Loro con i makefile ci fanno proprio quello.
 
Sti post sono sempre piu` monotoni... Sempre alla ricerca di uno
standard uguale per tutti, tutti uguali e nessuno diverso...
L'OpenSource _NON_ e` questo.
Chi dice 'Se l'opensource facesse x o y' dice una cazzata. Il movimento
si sviluppa in base a tutti gli eventi che accadono, anche all'interno
di esso. Quando ci sono progetti diversi nessuno vieta a un progetto di
_COPIARE_ il codice dell'altro, esattamente come i vari xmule, amule,
lmule hanno fatto con emule.
Il discorso e` complesso e non si puo` esaurire in questo 2 o 3 linee
che ho scritto sopra. Sostanzialmente se si conoscesse il significato di
concorrenza si potrebbe capire che avere un solo prodotto non significa
automaticamente che il prodotto sia migliore.
Ogni formato di pacchettizzazione ha vantaggi e svantaggi, a te capirli.


 ed aspettare.
Ora ti dirà che suo nonno non deve aprire una consolle per installare
qualcosa. Allora gli si indicherà un frontend grafico, ma suo nonno ha
trovato il gioco XYZ versione ultra-pre-alfa che però è fighissimo e in
Portage ancora non c'è, e che non va bene lo stesso.
Se per caso in portage ci fosse, allora ovviamente compilare diventerà una
menata di balle e una perdita di tempo, voglio il binario.
E si ricomincia da capo...
PS ah, dimenticavo l'ultima profezia: ora arrivaerà Ginopilotino che dirà
"guarda che è la triste verità di Linux quello che scrivi". poi arriverà
Valentino che gli dirà....
ok ok la pianto :P
-- 
il Vide - ICQ #5301833
http://www.heavy-metal.it
Sometimes we need to be cruels to be kinds
NP: Nulla


I sorgenti servono per coprire il fatto che Linux
non garantisce la compatibilità binaria. Questo è
il problema. E voi ci mettete pezze su pezze sopra
senza capire qual è il vero nocciolo della questione.
Saluti
Vegeta

 senza capire qual è il vero nocciolo della questione.
visto che linux non e' sviluppato da un'entita centrale , e' materialmente
impossibile che creare un programma che giri su qualsiasi distro , a meno
che tale programma non usi nessuna shared library. l' unica  soluzione al
problema ,visto che linux e' open source e chiunque
 puo' distribuirlo ,sarebbe andare in giro armati di ak-47 minacciando
 fisicamente chiunque  distribuisca un linux che non rispetti la
 compatibilità binaria .
se vuoi installare praticamente *qualsiasi* programma open-source , devi
usare una distro 'source-based ' come la gentoo .
il problema comunque rimane valido per i programmi closed-source .
d'altronde , linux originariamente era stato pensato come o.s. per hacker
, e quindi e' semplicemente 'fedele a se stesso' , per cosi' dire .
se vuoi delle *garanzie* che tutto funzioni bene devi scordarti la parola
'gratis' . 
per curiosita , qual e' il programma che in 3 ore non siete
riusciti a installare su una suse 9.2 ?

 Ogni formato di pacchettizzazione ha vantaggi e svantaggi, a te capirli.
Naturalmente. Ma i formati evolvono, e cosi' dovrebbero fare anche i
pacchetti sorgenti.
Tutto IMHO
ciao,
-Francesco

On Fri, 10 Dec 2004 20:07:53 +0000, luce della vita wrote:
[....]
Scusate, sono sempre io, ho postato con il profilo sbagliato :''(
sorry
-Francesco Stablum

 8.0.2 a 8.0.3 di BBEdit ma pazienza...
Concludo con questa frase: l'uomo e' morto se non tende a migliorarsi, e
aggiungo: cio' include anche il MacOSX ;^)
ciao,
Francesco

 riusciti a installare su una suse 9.2 ?
Suprem
Saluti
Vegeta


Infatti, HaikuOS, che è opensource, viene sviluppato in base
al modello caotico di Linux giusto?
Anche FreeBSD se non erro. Anche lui NON garantisce la
compatibilità binaria degli eseguibili, nevvero?
Insomma... Open source secondo te significa "che ognuno
faccia un pò quello che vuole". Sono contento che tu
ne sia convinto.
Saluti
Vegeta

 *garanzie* che tutto funzioni bene devi scordarti la parola 'gratis' .
Di strada ne e' stata fatta parecchia da quei tempi. Oggigiorno il target
di linux comincia ad estendersi, e linux diventa spessissimo un
prodotto che offre ben precise garanzie.
-Francesco

 senza capire qual è il vero nocciolo della questione.
Linux in quanto TALE no. SuSE garantisce che se tu utilizzi i programmi 
binari suse funziona. RH anche. Windows anche. MacOSX anche. Strano, ma 
windows NON garantisce la compatibilità binaria con i programmi che non 
hanno la certificazione. O no?


 ne sia convinto.
No, assolutamente no. Ho sconsigliato a qualcuno di aiutare il progetto 
C6 ma di dar le forze a kopete o gaim. E questo per economia di forze. 
Hanno vinto loro, e Licq ha perso.



Quale certificazione?
Saluti
Vegeta

 per usi non commerciali).
anche Haiku avra ' dei fork , e anche allora ci saranno applicazioni che
girano su Haiku_variante1 ma non su Haiku_variante2 ; perche tra qualche
anno un gruppo di gente se ne uscirà con dei ragionamenti del tipo "l'API
e' vecchia , cambiamo questo in quest'altro" e qualcun 'altro dirà : "no,
mantieniamo la vecchia" oppure "secondo me bisognerebbe ..." e si
creeranno due sistemi operativi con API e librerie diverse; in poche
parole,si  ricomincia da capo .
 
Haiku sarebbe comunque un passo in avanti rispetto a linux ,perche
progettato sin dall' inizio come OS desktop : il problema e' che
bisognerebbe fare il porting di moltissime applicazioni che ora girano su
linux.

 
giusto , pero' non 'linux' in generale : "Red Hat linux" , "Suse linux" .. 


Lo stanno facendo con SkyOS, si farà di sicuro (e
molto più facilmente) con OpenBeos (Haiku).
Io sono convinto che Haiku sarà ciò che Linux
non è stato: un buon sistema operativo per uso
desktop, con standard, tecnologie moderne,
coerenza e pulizia, velocità, sicurezza, e
soprattutto free ed open-source.
Saluti
Vegeta

> > Che faccio?
la procedura corretta sarebbe stata compilare anche la libreria aggiuntiva
dai sorgenti  (magari in una directory differente), e non usare l'RPM; a
questo punto vai a modificare /etc/ld.so.conf e poi esegui "ldconfig" .
Inoltre si tratta di un programma proprietario , che la ditta rilascia per
una specifica distribuzione linux , che scommetto non e' la suse ..
in parole povere , fatti installare il prog. da un ing,informatico o
comunque da qualcuno che abbia fatto l'esame di  sistemi operativi e sa
cos'e un linker .
in alternativa ,e' possibile alterare il makefile creando un eseguibile
statico.

 punta-e-clicca, dopotutto).
E questo chi lo ha stabilito ? lo zio bill o pinkopallino ?
definire "utenti normali" prego, io mi sento un utente "normale" (piu o
meno !) faccio il meccanico, uso indifferentemente Slack o debian
(preferisco la prima!), e quando non trovo cio che mi serve mi compilo il
sorgente,anche se è molto poco cio che non trovo gia pronto (ho poche
pretese)
mi pare che tu ti riferisca ad una specie di installatore/compilatore di
sorgenti universale, per quanto ho potuto sperimentare esistono gia
parecchi sistemi simili: su gentoo,freebsd,archlinux e qualcun'altro che
ora mi sfugge............francamente dopo averli provati praticamente tutti
mi sono ricordato perche *ADORO* Slack,  niente tools automagici se
escludiamo swaret e checkinstall,niente casini con dipendenze irrisolte (al
massimo non funziona e finisce li) ........................
l'altra mia favorita (debian) è gia troppo "evoluta" per i miei
gusti......... 
spero di aver capito male, ma mi sembra che il tuo ideale sia qualcosa di
simile ai  Setup.exe di casa microsoft .....................vade retro !
-- 
http://distrowatch.com
 (linux e dintorni)
www.slacky.it/tutorial/slackware_for_dummies/slackware_for_dummies.txt
46=pilota che vince !
Hai un milione di buoni motivi per non usare Windows..

 ne sia convinto.
Non secondo me, ma secondo chi sa cosa vuol dire OpenSource, tu che non
capisci neanche che 'ognuno faccia quello che vuole' significa che se
vuoi fare l'hitler e tenere un progetto in quel modo puoi farlo.
Peccato che tu non conosca l'italiano, sarebbe un buon investimento.


 ok ok la pianto :P
Meglio va :).


 pacchetti sorgenti.
Se hai una soluzione migliore di make proponila, se sara` migliore
verra` usata. Finche` nessuno si lamenta _costruttivamente_ make resta
li`.


 Ricorda poi: perfetta _NON_ vuol dire NON migliorabile.
In tutto l'universo conosciuto vuol proprio dire il contrario invece. Una 
cosa perfetta non e' perfettibile.
Saluti. 

 Come fare a incentivarne una diffusione capillare?
è una domanda retorica? ovviamente, deve supportare tutti i makefile 
esistenti ed avere almeno una implementazione di riferimento nella 
licenza più libera possibile

 leggere. Quasi mai questo avviene.
nel mondo delle fiabe, magari. In realtà nessuno documenta i parametri 
validi per configure, e il configure non documenta mai se stesso. Si va 
sempre un po' alla cieca, e bestia se i readme ne parlano

 1. dillo alla MS perchè anche lei lo usa
internamente usano makefile, ma non make. C'è un complicatissimo coso 
chiamato "build" che mantiene le dipendenze e invoca nmake in passate 
multiple su makefile basati su un gigantesco unico template che può 
compilare di tutto, dalla DLL al kernel di Windows. Il risultato di 
tutto l'ambaradan è che tu scrivi solo un file DIRS con i nomi di tutte 
le directory da attraversare ricorsivamente, e un file SOURCES nelle 
directory contenenti i sorgenti con la lista dei file da compilare. Un 
esempio di file DIRS:
DIRS= \
     cpsuisam \
     genprint \
     mini \
     monitors \
     msplot \
     oemdll \
     pp \
     tty
e un esempio di file SOURCES:
C_DEFINES=-DUNICODE -DNO_STRICT
!IFNDEF MSC_WARNING_LEVEL
MSC_WARNING_LEVEL=/W3
!ENDIF
MSC_WARNING_LEVEL=$(MSC_WARNING_LEVEL) /WX
USE_NTDLL=1
TARGETPATH=obj
TARGETNAME=genprint
TARGETTYPE=DYNLINK
DLLDEF=winprint.def
DLLORDER=winprint.prf
TARGETLIBS=$(SDK_LIB_PATH)\kernel32.lib \
           $(SDK_LIB_PATH)\spoolss.lib  \
           $(SDK_LIB_PATH)\user32.lib   \
           $(DDK_LIB_PATH)\gdi32.lib
SOURCES=winprint.rc \
        parsparm.c  \
        support.c   \
        winprint.c  \
        emf.c       \
        local.c     \
        util.c      \
        text.c      \
        raw.c
In ReactOS usiamo qualcosa di molto simile, ma stiamo considerando il 
passaggio ad un unico makefile fatto di tanti piccoli include

 
chi vivra vedra' .. c'e stato anche syllable, atheOS ..

 rispetti la compatibilità binaria .
altre cazzate. Linux è un marchio registrato. Una cosa fatta bene, se a 
chi vede e provvede non fregasse soltanto di costruire un fantastico 
giocattolone, sarebbe vietare l'uso della parola "Linux" per riferirsi 
a sistemi derivati ma non compatibili

 comprese nello standard che si fa ?
se le porta dietro col suo programma e le tiene nascoste agli altri 
programmi. O cerca di farle standardizzare

 e anche cosi' ha comunque problemi di gestione delle librerie ..
no, non ne ha. Leggili, i link che posti

 puoi sapere.
http://www.freebsd.org/doc/it_IT.ISO8859-15/articles/explaining-bsd/x119.html
Cite:
BSD gestisce gli aggiornamenti della versione di libreria fornendo moduli di 
compatibilità per le versioni precedenti, dunque è possibile eseguire binari 
di parecchi anni prima senza problemi
Qui il cialtrone non sono io, ma qualcun'altro.
Saluti
Vegeta

 senza capire qual è il vero nocciolo della questione.
Il nocciolo della questione è che Linux ha una filosofia di base diversa
da quella di windows, insomma è il classico discorso delle librerie
static vs shared.
Una cosa interessante da notare è che i software scritti con i moderni
linguaggi di scripting (perl, python) uniscono i vantaggi dei programmi
sorgenti (adattabilità al sistema) con quelli dei pacchetti binari (non
è necessario compilare ...).
-- 
Do I look like a freakin' people person?
 
 |\ |       |HomePage   : 
http://nem01.altervista.org
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 che usi solo apt-get o 
debian.org
?
Beh quando usavo debian il mio freshmeat era 'apt-cache search' :-D
-- 
According to my calculations, the problem doesn't exist.


 milioni di lire.
Beh ma se si parla di uso domestico e tu te ne esci con un esempio di
un software closed per un uso mooooolto di nicchia ....
Non penso che il nonnetto di cui sopra abbia bisogno di questo suprem.
-- 
Cole's Law: thinly sliced cabbage.



E' la maledetta filosofia del "make it simple stupid" di
Unix che crea i danni. In pratica si è spostata la
complessità del problema dal software, all'utente.
Come dire che sotto Windows c'è un codice
estremamente sofisticato, che fa fare le cose
semplici agli utente.
Sotto Linux c'è un codice troppo semplice (cioè per
molte cose ti manca l'architettura di sistema ed
allora devi metterci pezze su pezze), ed il
problema si sposta sull'operatore
che deve sbattersi oltre ogni inverosimile.
Ragionamento molto semplice: perchè le librerie
devono avere le versioni incluse nel nome?
Se le librerie avessero solo un nome (senza
versione), per esempio LIBTIX.LIB, e la
versione fosse interna, si potrebbe pensare
ad una soluzione banale.
C'è un server di sistema, detto gestore di
linking, che tiene un database di tutte le
librerie.
E quando un pezzo di codice ha bisogno
di una libreria, chiede al gestore di linking
che lo collega dinamicamente all'ultima
versione della libreria disponibile.
Se la libreria invece non è disponibile, il
processo viene posto in attesa e la
libreria viene scaricata automaticamente
da Internet.
A questo punto devo solo occuparmi di:
a) garantire la retrocompatibilità di tutte
le librerie;
b) creare una versione del GCC che mi
garantisca compatibilità binaria tra ogni
versione e la successiva.
Non si fa perchè ormai è troppo tardi (e
perchè sono stati troppo miopi all'inizio per
pensarci), non perchè è tecnicamente
impossibile.
Saluti
Vegeta

 Rileggiti quello che hai scritto. E ridici sopra.
Certo e se da:
Se non vieni domenica a pescare tra amici ti ammazzo
estrai solo
ti ammazzo
la frase cambia completamente di significato.
Purtroppo non ho voglia di litigare con te pirlino. Continua pure da
solo


 Quale certificazione?
L'inutile scritta ``for WindowsXP''.


 sempre un po' alla cieca, e bestia se i readme ne parlano
Tutti i configure che ho usato fin'ora mostrano i parametri che hanno
con:
./configure --help
Se tu hai trovato configure che non lo fanno peccato.


 sempre un po' alla cieca, e bestia se i readme ne parlano
Si. Per questo io nel makefile del plasm metto le frasi tipo ``non è che 
per caso mi devi specificare dove è la libreria opengl con 
--with-opengl-library=PATH?''.
I sorgenti però sono sempre, e lo sosterrò, per chi comprende.


 licenza più libera possibile
Appoggio. Comunque, vedo inutilità in questo... sarà il mercato a 
stabilire se è utile o no.


 passaggio ad un unico makefile fatto di tanti piccoli include
Io fino ad ora preferisco il makefile con definizione di sotto progetti 
(i tuoi include?).


 li`.
Ecco il mio lamento costruttivo.
Obiettivo: creare un sistema per l'automatizzazione delle procedure (fino
ad ora troppo complesse) per la realizzazione di un file che descrive,
diversamente dal makefile, i dati necessari (e non i comandi) per la
compilazione e installazione di pacchetti sorgente da parte di una gui.
scrivo le idee di getto, magari la sequenza va "aggiustata".
Fase 1: analisi dell'output del configure script (magari con controllo
incrociato sul 
configure.in
) con argomento --help in questo modo si fara'
il parsing e la gui sara' in grado di chiederci come configurarlo (e qui
viene il bello) nella maniera, nello stile, nella grafica e nel gergo che
preferisce!
Fase 2: risoluzione delle dipendenze: il configure script da errore, viene
fatto il parsing sul messaggio e il programma "capisce" di cosa necessita.
Fase 3: eventuale risoluzione automatica delle dipendenze tramite il
sistema di packaging tipico della distribuzione in esame.
Fase 4: analisi del Makefile.am (oppure del Makefile stesso),
ricerca e parsing di Makefiles nelle locazioni indicate dal Makefile della
root. L'obiettivo e' quello di creare un elenco dei sorgenti da compilare
e l'utilizzo dei flag indicati da mandare al compilatore.
I file oggetto vengono creati, linkati e cosi' abbiamo i nostri eseguibili.
Fase 5: installazione tramite sistema analogo a checkinstall (quindi
creazione del pacchetto compilato adatto alla nostra distro).
Nota bene: il processo di analisi e parsing avra' come risultato la
creazione di un file di dati (xml?) che descrive il tutto in maniera
semplificata ed interpretabile dalle varie gui.
Se tutto questo e' andato a buon fine, mio nonno avra' il piacere di
installare e giocare con il suo shooter preferito, dopo aver assistito a
una semplice barra di scorrimento.
utopistico? Boh. Io ci provo.
ciao,
-Francesco

 ./configure --help
mai tutti. Tipo i --with-tazzi=mazzi. Mai visto uno che si degnasse a 
documentarli

 Ah gia'.. NON vengono gestiti in automatico. Piccolo particolare.
Non possono essere gestiti. Nessun sorgente può gestirli. Pretendete un 
po' troppo no?
I binari devono essere automatizzati.
I sorgenti devono essere come i binari.


 ci vorrebbe un installer grafico per ogni pacchetto sorgente, fossi matto!
e peche' no? Se si standardizzasse e si automatizzasse in qualche modo 
la situazione... uno scarica i sorgenti, vengono risolte le dipendenze e 
compilati in automatico, e viene installato il tutto... pensa che figata 
che sarebbe (e quanto sarebbe comodo). Ma dovrebbe funzionare su TUTTE 
le distro linux. Ma mi sa che e' destinato a rimanere un sogno.

 install.


 che tale programma non usi nessuna shared library.
Non ci vorrei insistere, ma ho citato in un post sopra il gioco 
"America's Army Operations", rilasciato dall'esercito americano 
(ovviamente in formato binario). Non e' proprio una cagatina, un giga e 
mezzo di roba che gira con il Karma Engine di Unreal Tournament, uno dei 
motori grafici piu' all'avanguardia fino a poco tempo fa... e AFAIK gira 
su *QUALSIASI* distro linux. Io personalmente l'ho installato 
nell'ordine su Suse 8.1, suse 9.0, Slackware 8.0, Slackware 8.2, 
Slackware 9.2, Debian SID, Knoppix, Fedora Core 1. Sempre lo stesso 
installer, e ha funzionato ovviamente su tutte.

 "guarda che è la triste verità di Linux quello che scrivi".
e anche lui non avrebbe torto, credo.

 semplificata ed interpretabile dalle varie gui.
xml non e` mica necessario... 
Dato che rpm e deb sono tutti standard aperti, perche` non aprire il
formato e controllare nei rispettivi posti le dipendenze ecc ecc ecc?
C'e` gia` alien che converte da rpm a deb, per convertire da deb a rpm
non dovrebbe essere molto difficile (parimenti).
Ecc ecc ecc. 
Se devi compilare da sorgenti via interfaccia grafica puoi scrivere una
GUI al ports system, o a darwinports ecc ecc.
Fare la cosa automaticamente _NON_ e` semplice e non vale la spesa di
aggiungere poche istruzioni di build a mano.


 Ma mi sa che e' destinato a rimanere un sogno.
L'uomo senza sogni e' un uomo che non tende a migliorarsi, quindi un uomo
morto con funzioni biologiche attive, IMHO. I sogni diventano spesso
realta'.
ciao,
-Francesco

 I binari devono essere automatizzati.
mi dai delle linee guida per fare un programmino molto semplice che sto 
facendo fare da un mio amico in questi giorni che possa funzionare su 
QUALSIASI distro linux con relativo installer? No perche' noi ci stiamo 
un po' perdendo. Su windows e' stato un attimo, ma su Linux non riesco a 
intuire come fare. E' un programmino quasi banale, un semplice binario 
con un interfaccia grafica che deve modificare dei file di testo e 
lanciare poi dei binari passandogli dei parametri,  ma NON deve avere 
dipendenze di nessun tipo. Cioe' se mi rispondi "puoi farlo con le GTK 
ma poi sul sistema ovviamente dovranno esserci le GTK" la risposta NON 
e' valida. Voglio qualcosa che giri su qualsiasi distro linux, 
indipendendentemente dal fatto che sul sistema ci siano GTK, QT, 
GTk-WxWidgets, Motif e quanto altro ti pare. Deve essere una cosa che 
gira ovunque.
E l'installer come lo faccio? Mi devo creare un .deb per debian, un .rpm 
ciascuno per ogni versione di suse, di Red Hat, di Mandrake, piu' un 
pacchetto ad Hoc per le varie versioni di Slackware? Ci metto una 
settimana solo a preparare i vari installer.
Ma sicuramente sono io che non so come fare. Qualcuno ha da darmi 
qualche buon consiglio in merito per far si che io possa creare un UNICO 
installer binario che funzioni su qualsiasi distribuzione linux?

 a seguire uno standard perchè non esistono standard.
Si, infatti la Linux Standard Base (recentemente arrivata alla versione
2.0) non esiste, né vengono definiti standard quali il Filesystem
Hierarchy Standard.
+++
Vegeta, adesso basta: stai sparando nel mucchio, e stai sparando pure
stronzate, seguite dal vuoto pneumatico più assoluto. Hai un'idea di
Linux che fa acqua nel caso medio, ed è completamente sbagliata
altrimenti. Non ne conosci l'archiettura, ti ostini ad usare un modello
centralizzato per *tutto* il software, quando uno dei punti cardine del
paradigma è la decentralizzazione. Banalmente, è come se io parlassi
delle API di WindowsXP, pur non programmando su Win32 dal 1995.
Se hai proposte serie, comincia ad organizzare una comunità di persone
con le tue stesse idee, poi convinci tutte le distribuzioni a seguirti.
Nel frattempo, non venire a cianciare del nulla - per poi dire, quando
ti si chiede di realizzare quello di cui vai scrivendo: "ma a me non
interessa"; perché se non interessa *a te*, figuriamoci al resto del
pianeta.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 poche istruzioni di build a mano.
Naturalmente ci potra' sempre essere l'intervento umano in casi
problematici. Non ho detto che sia una cosa semplice.
-Francesco

 Ma sicuramente sono io che non so come fare
Compilare tutto staticamente dentro no eh? Poi fai uno di quei bei .sh
autoestraenti et voilà.
-- 
il Vide - ICQ #5301833
http://www.heavy-metal.it
Sometimes we need to be cruels to be kinds
NP: Nulla

 installer binario che funzioni su qualsiasi distribuzione linux?
InstallAnywhere mi pare funzioni egregiamente. Includi tutte ma tutte le 
librerie nel tuo progetto (tutte!) e rimani felice. Cosa credi che 
facciano per i giochi? Le SDL le hanno nel progetto. X assumi di averlo. 
Tutto l'altro, includilo. Dopotutto si fa così anche su windows e mac.


 autoestraenti et voilà.
... staticamente ... cosa vorra dire mai questa parola magica ??!? :D
adesso che hai commesso l'errore di dargli la risposta, ti tocchera' pure
spiegargli come fare ;)

Salve a Tutti,
Ho letto il vostro dibattito su questo e mi e' venuta una semplice
domanda da farvi ma prima vi racconto una storiella...
Una volta ho visto un programma per windows che serviva ad installare i
mod per GTA vice city. Questo programma era veramente carino perche'
era in grado di capire da un file readme inglese alcuni dati che
servivano all'installazzione. Ora noi stiamo parlando di un MakeFile e
un un configure che sono gli standard di fatto; esistono 2 programmi
che secondo me sono anche loro standard di fatto Automake e Autoconf.
Tutti voi sapete a che servono... Questi programmi (mi spiegava
Francesco) lavorano tramite delle macro... Ora perche' non realizzare
una semplice GUI per eseguire il risultato di queste macro? Per esempio
si potrebbe scrivere un piccolo programma grafico che apra una macro di
autoconf la interpreti eseguendo un controllo sulle dipendenze e poi
lanciando un make in una piccola finestra nella GUI.
Nella discussione linux viene accusato di coprire cose obsolete con
frontend o GUI (quello che vorrei fare io in altre parole) ma vorrei
farvi una domanda... Perche' buttare una cosa che ha sempre funzionato
bene? e' Perche' non cercare di migliorarla? Perche' dire "Make e'
obsoleto" quando e' una cosa che ha sempre funzionato e che accomuna
tutti i linux? Allora non dovrebbe essere obsoleta anche la shell sh???
Infondo ormai c'e' X che fa tutto in grafica!!!
Quello che voglio dirvi e' che io ho scelto linux per questa sua
capacità di eseguire cose vecchie e spesso obsolete ora volete dirmi
che questo (a mio avviso il suo punto di forza) e' una debolezza? Non
credo proprio Perche' questo essere legato alle tradizioni di linux e'
proprio quello che gli impedisce di diventare come windows in cui un
programma da 70€ per windows 98 sull'XP non funziona più. Per farvi
un esempio mio padre da ragazzo lavorò su System V e Xenix e quando
vide la shell di linux si ritrovò subito a suo agio perche' i comandi
erano uguali e quindi per lui era facile da usare.
Comunque sto divagando... Xke' invece di accusare make di essere
obsoleto non mettiamo per iscritto cosa servirebbe per aggiornarlo,
scarichiamo i sorgenti e lo modifichiamo come piace a noi? Xke' non
trasformiamo make in una libreria a link dinamici e non trasformiamo
l'interfaccia testuale in un wizard grafico?
Penso che non servirebbe molto si tratterebbe solo di creare un
programma (tipo con il QT designer presente in tutte le distribuzioni
che supportano KDE) che processi i makefile e faccia una bella
finestrella con scritto che combina... Non vi sembra un'ottima
soluzione?
Per quanto riguarda il vecchio zio ;-) perche' invece di usare una
debian non usa una Mandrake? Infondo se non gli interessa imparare a
programmare e altre cose molto avanzate ma solo un uso desktop la
distribuzione Mandrake e' l'ideale!!!  (non sto dicendo che la debian
e' male anzi la trovo ottima).
Infine vorrei rispondere a Sensei...
I sorgenti sono per tutti e deve essere permesso a tutti di
ricompilarli (anche senza capire che succede in realtà) perche' solo
così si avrà sempre la certezza di trovare un modo di far funzionare
un programma su tutti i linux...
Snake88
PS scusate se non ho usate e accentate ma non ero sicure che si
leggessero quindi ho preferito il vecchio e' ;) ciao!

 un programma su tutti i linux...
No. I sorgenti sono comprensibili solo da chi li comprende (grossa 
tautologia). Se accade un errore che fai?
Puoi *ricompilarli* magicamente con i tool, ma di sicuro non correggi 
errori se accadono. A questo punto, è logico pensare che il sorgente per 
chi non sa nulla equivale al binario, con le sostituzioni:
setup.exe ---->  ./configure
next      ---->  make
install!  ---->  make install


 fregare di meno.
Se per "lavorare" intendi scrivere un paio di emails, cazzeggiare su 
internet e scrivere una lettera con un word processor grafico allora hai 
ragione.
Per il mio lavoro i Makefiles sono molto utili (e non faccio il 
programmatore!).
-- 
Lorenzo "Paulatz" Paulatto
Trieste
Dagli errori di Windows 98:
1070 0x042E Dopo l'avvio, il servizio si č sospeso in uno stato di attesa.
1440 0x05A0 Schermo gią bloccato.

 Tutto l'altro, includilo. Dopotutto si fa cosě anche su windows e mac.
eh gia', loro sono fessi.

 autoestraenti et voilà.
E per fare un applicazione di 50k scarsi mi devo tirare dietro quanti 
mega di librerie (gtk o qt che siano)?


No. E' sufficiente ragionare nel seguente, semplicissimo, modo.
Dunque, noi abbiamo creato una distribuzione che è
fatta nel seguente modo:
a) tutti i drivers si basano su questo tale standard e si
installano con questo, medesimo, programma grafico.
I binari progettati per la rev. 1.00 girano, senza alcuna
modifica, su tutte le distribuzioni conformi allo standard.
Anche in caso di aggiornamento del kernel ad una
versione successiva, i medesimi drivers continuano a
funzionare sulla nuova versione. Ove fosse necessario
cambiare le interfacce di comunicazione tra drivers
e kernel, gli sviluppatori del kernel di dLinux si
impegnano a inserire nel codice del kernel due
sottosistemi che gestiscono sia i vecchi che i nuovi
drivers, in modo da garantire la retrocompatibilità.
b) gli applicativi si installano nel medesimo modo. Ogni
applicativo ha un installer che comunica con un servizio
di sistema chiedendogli di fare delle cose. Il servizio di
sistema si occupa di eseguire compilazioni, scaricare
librerie, mantenere in usr/lib versioni diverse della
medesima libreria ecc. ecc. in modo totalmente
trasparente all'utente.
c) l'interfaccia grafica del sistema si basa su queste API,
e su questo toolkit che è standard, in modo che si
possa scrivere un installer che funzioni su
ogni distribuzione aderente allo standard.
e) la configurazione delle connessioni di rete ed internet
si fa sempre nel medesimo modo.
f) la struttura del file system è perfettamente standardizzata
g) ogni distribuzione installa, di default, le librerie A,B,C,D,
e gli interpreti di scripting A,B,C,D. Entrambi sono stati
reingegnerizzati per garantire ampia retrocompatibilità con
vecchie applicazioni.
h) c'è un BIOS driver e la possibilità di installarlo in un
partizione di loopback e di fare il boot da Ms-Dos (niente
smanettamenti con la tabella delle partizioni, niente
casini con Lilo e Grub).
i) non c'è più quella schifezza di X-Windows
l) le opzioni di compilazione del GCC sono tutte standardizzate,
come le librerie di runtime C. Compatibilità binaria a tutti i
costi.
A questo punto dLinux la gente comincia ad installarselo,
usa quel primo 25% di applicazioni per i quale già c'è già il
porting (che poi sono le solite, Mozilla, Firefox, OpenOffice,
MuPad, PostgreSql, Acrobat, Gimp, Blender, Xine ecc. ecc.),
manda a fanculo Mandrake e Fedora, ed abbiamo trovato una
alternativa a Windows.
Gli altri, o si reingegnerizzano i loro sistemi per rispondere ai
nuovi standard, oppure se ne falliscono serenamente....
Capito come si impongono gli standard software?
:)))))
Saluti
Vegeta

 e' male anzi la trovo ottima).
[cut]
Si, ma il topic non era "lo zio e linux", ma "lo zio e i sorgenti".
ciao,
-Francesco

 segue i classici standard.
ma come ? ma se gli standard sotto linux non esistevano ...

 mega di librerie (gtk o qt che siano)?
Perchè, OSX come fa? e Windows?
Non è che le librerie si inventano dal nulla...se servono servono, e
occupano spazio. Poi, cmq, se compili staticamente non ci devi mica mettere
tutto tutto delle QT (ad esempio), ci metti solo quello che la tua
applicazione utilizza.


 eh gia', loro sono fessi.
Non comprendo... è inefficiente ma sei al riparo da tutti i cambi di 
libreria.



Come mai i programmi scritti per Windows for
Workgroup mi girano sotto Windows XP?
Saluti
Vegeta

 Non penso che il nonnetto di cui sopra abbia bisogno di questo suprem.
Eh ma è classico saltare di palo in frasca per appoggiare sempre e cmq la
propria tesi anche quando ti fanno notare che fa acqua da tutte le parti.



Vide, se domani Microsoft facesse uscire un sistema
operativo in cui ti dice: "Tu puoi installare facilmente
solo il software che ti forniamo NOI", voi parlereste
di blackbox e di limitazioni della libertà dell'utente.
Riflettici.
Saluti
Vegeta

 libreria.
ma chissenefrega dell'inefficenza se questo mi fa risparmiare 2-3 ore 
perse a compilare e a risolvere dipendenze! E' proprio questo il punto! 
Io sinceramente dopo 2-3 anni di utilizzo abbastanza intenso di Linux 
(Debian e Slackware) sto tornando ad utilizzare Windows per tutto. Mi 
sono rotto abbastanza le palle di dover perdere a volte 3 ore per 
installare un programma che non sia nel repository, di conflitti nelle 
librerie, del fatto che a volte per compilare un programmino del cazzo 
ti devi tirare giu' 50 mega di librerie aggiuntive, o del fatto che per 
capire come configurare a volte anche questi programmini della minchia 
ci metti le ore (i wizard ti fanno risparmiare MOLTO TEMPO rispetto alla 
configurazione a mano nei file di testo... e il tempo ha un suo valore).
Insomma, da utente linux un po' scocciato e con sempre meno tempo libero 
a disposizione (per cui il poco tempo che ho voglio passarlo a fare 
qualcosa di interessante al pc, non a configurare il sistema operativo o 
il programma di turno semplicemente per farlo funzionare) in molti punti 
concordo con il discorso di Vegeta. Sotto linux c'e' troppo casino, e 
l'utente medio "end user" non ha tutto questo tempo da perdere per 
mettersi li e dipanare la matassa. Usa windows perche' funziona subito 
(magari a volte non proprio in maniera ottimale, ma subito). Ecco 
perche' Linux non e' ancora pronto per il Desktop, e stando cosi' le 
cose non lo sarà mai.

 cosi' le cose non lo sarà mai.
A meno che non salti fuori qualche pirla che prenda un po' di tempo per
semplificare le cose ;)
-Francesco

 Riflettici.
Mmmmmh. Fatto.
Hai detto una cagata, come al solito, perchè il raffronto con Linux è
improponibile. Lo vuoi capire una volta per tutte che non esiste nessuna
minchissima LINUX INCORPORATED???
Di distro, come tu e altri qua dentro vi divertite tanto a criticare, ce ne
sono fin troppe, e questo già da sè è una prova inconfutabile che il
ragionamento che fai è fuori da qualsiasi senso logico.


 ragionamento che fai è fuori da qualsiasi senso logico.
Senti, Vide, perchè tutta quella manica di cialtr...
/mode linuxaro on
(pardon, stimatissimi professionisti dell'informatica
che tengono in conto i loro clienti, non come quei
monopolistici come Ballmer e Gates che ti danno
Winzozz con i bug)
/mode linuxaro off
come i tecnici di Novell, RedHat, Mandrake, non si
riuniscono con Linus Torvalds e magari Stallman
e non fanno qualche accordo nell'interesse dei
clienti?
Poi, si fanno qualche serio test di usabilità sui
prodotti finali, valutando in quanto tempo un
utente risolve un problema e quali sono le
sue esigenze.
E poi ti risulta che ci sia presente una Haiku inc?
Eppure loro tutto questo schifo non lo fanno.
Ed infine, questa simpatica giustificazione fa
semplicemente ridere. Ed a me utente finale
che me ne frega? Male, vuol dire che resto
con Windows per l'eternità
Riflettici.
Saluti
Vegeta

 con Windows per l'eternità
Ah, non GalaxyOS?


 purtroppo non sono presenti.
ma come fa uno sviluppatore  a fare il datafile per tutti i sistemi su 
cui girerà il suo programma? se lo fanno le distribuzioni allora sei 
tornato ai pacchetti delle distro.
-- 
Non c'è più forza nella normalità, c'è solo monotonia.

 clienti?
Perche` tu sei un'idiota che non ha capito che a Linus non gliene puo`
fregare di meno. Non ti piace? Non usarlo e non scassare.
C'e` gente a cui piace e che lo usano, ti da fastidio perche` tu che
vuoi scrivere un os non lo sai usare e mia madre che non sa accendere un
monitor si? Peggio per te.
Ci sono ottime case di riposo nella zona milanese, posso fare il tuo
nome a qualcuna di loro, magari ti accolgono.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.6
Blog: 
http://vvolonghi.blogspot.com
http://developer.berlios.de/projects/weever


Oh, si. Piace a tutti.
Infatti come os desktop lo usano si e no
il 3% delle persone.
Ed un negoziante della mia zona mi
ha detto che non ha venduto,
in tre anni, UNA (leggi UNA) scatola di
Suse 9.0.
Se non ci fosse stata la magica
propaganda "è windows, ma stabile e
soprattutto GRATIS", non si sarebbe mai
diffuso in ambito diverso dal server. Questa
è la verità.
Comunque tu continua con le tue simpatiche
cazzate, tanto per quello che me importa....

 cazzate, tanto per quello che me importa....
Io continuo con le cazzate? Ma tu non finisci mai di rosicare?


 nessuna minchissima LINUX INCORPORATED???
guarda che sta parlando delle distribuzioni. E finchè nessuna riesce ad 
uscire dallo stereotipo Linux = GNU + idiosincrasie + proprio package 
manager (alla faccia del "Linux è solo un kernel"), è anche autorizzato 
a generalizzare e a dire solo "Linux"

 su cui girerą il suo programma?
uh, ne fa uno solo?

 questa specifica, magari.
comunicazione di servizio: Linux è un marchio registrato. Impedire che 
venga appiccicato a sistemi non compatibili è legittima protezione del 
marchio. Che a chi può farlo non freghi niente è il problema di cui si 
sta parlando

 i) non c'č piů quella schifezza di X-Windows
non confondere quello che serve fare con quello che ti piacerebbe 
tanto. In piů usi una lista puntata/numerata. Cosě dai solo un pretesto 
alle comari per attaccarsi alle sottigliezze e rispondere riga per riga

 Perchè, OSX come fa? e Windows?
sono sistemi in cui l'alternativa non è XLib

 dall'rpm (QUALSIASI rpm).
 E' vero, Valentino, io come ho detto spesso sono un fanatico della slcak
 a da poco mi sto convertendo a debian...E' la pace dei sensi informatici..
Ho installato la unstable due settimane fa senza alcun problema sulla
"bestia" amd64, bene ieri con apt-get mi sono upgradato tutto il sistema
in poco tempo, senza conflitti, dipendenze e cazzi vari. Una favola, altro
che win e mac...



La mia idea era quella di creare il Datafile su analisi dei Makefile.am
configure.in
 ecc. Infatti bisogna partire dal presupposto che questo file
non esista nei sorgenti.

* KJK::Hyperion [2004-12-13 04:11]:

Stai confrontando mele con pere: il marchio registrato impedisce di
chiamare un altro kernel "Linux". Fino a che una distribuzione che si
basa sul kernel rollato da Linus Torvalds (con patch più o meno custom),
allora non viola nessun marchio registrato - né potrebbe farlo, dato che
rientra nella piena facoltà (secondo licenza) di un distributore farlo.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 E un bel "chissenefrega" non ce lo mettiamo?
Ah bhe, a me non frega molto.
A qualcun altro dovrebbe fregare, ma vedo che questo
qualcun altro non se accorge. Peggio per lui.

 uh, ne fa uno solo?
ma c'è il problema che gli autotools nelle varie versioni non si 
comportano sempre uguali.


 qualcun altro non se accorge. Peggio per lui.
A me del gratis non me ne frega nulla... Con l'universita` ho gratis
anche windows perche` ho le licenze universitarie date dal politecnico,
ho anche MacOSX sull'ibook e linux nell'altra partizione sul fisso... Me
ne strafrego del gratis o meno idiota, io non sono un morto di fame come
te. Vai a lavorare LAVATIVO.



Veramente io sono un professionista serio. Qui chi
parla come uno studentello morto di fame sei TU
e solo TU. Altri professionisti seri di questo NG non
hanno mai pensato di parlare con il tuo linguaggio,
che poi è quello di un accattonello del New Barbonia,
a cui hanno regalato un computer.
Vedi di andare per l'ennesima volta a fanculo, và,
che mi hai davvero scassato u cazzo. Torna
quando hai imparato l'educazione, buffone.

 quando hai imparato l'educazione, buffone.
Torna quando hai imparato qualcosa, basta anche l'alfabeto. La prossima
volta te lo chiedo tutto.
