Ubuntu Dapper Drake dev +++

[riko]

Quelli sui linguaggi "interpretati" sono quasi tutti pregiudizi.

A parte che nei linguaggi interpretati ci sono tre categorie diverse di interpreti:

1) Interpretati puri: il codice viene letto riga per riga e valutato (per esempio bash, tcsh, certe implementazioni di prolog)
2) Interpretati bytecompilati: il programma viene compilato nel cosidetto bytecode, la macchina virtuale interpreta poi questo.
Di questa categoria fanno parte linguaggi molto diversi fra loro. I vecchi Java, Perl, Ruby, Python, Lisp. Con prestazioni molto diverse. Da un lato il vecchio Java, abbastanza lento, dall'altro Lisp, che in certe implementazioni è +/- 5% prestazionale di equivalente codice C (anche se scritto in circa 5 volte meno tempo).
3) Interpretati con JIT. Nuovo Java, .Net. Qui le prestazioni si prevede che in breve tempo *supereranno* quelle dei tradizionali linguaggi compilati.

Da un lato una sempre maggiore ottimizzazione degli algoritmi di GarbageCollector porteranno a ottimizzazioni e migliorie che in media supereranno la gestione manuale della memoria. Dall'altro un linguaggio compilato "Just In Time" potrà godere della massima ottimizzazione possibile sulla specifica macchina, laddove invece un compilato commerciale dovrà essere per forza compilato a minimo comun denominatore.

CLR di Microsoft in questo è sorprendentemente buona. Hanno prestazioni davvero incredibili. Mono è pure abbastanza buono, anche se non altrettanto veloce.
Dopo soli 6 mesi di sviluppo IronPython (ovvero un'implementazione ci Python per .Net) girava in media più lento di un fattore due rispetto all'interprete "standard". Faccio l'esempio di un interprete perchè è un programma che deve fare praticamente di tutto.

Riguardo Java (che a me proprio non piace) non è vero che il linguaggio sia lento. In un uso tipico (da server) non è sostanzialmente più lento di codice C++ -- nulla di davvero rilevabile --,
Idem in applicazioni scritte bene. Perfino su certi algoritmi numerici riesce a superare addirittura C++ [ non su tutti gli algoritmi, ovviamente ].

La percepita lentezza di Java è dovuta a cattive esperienze con Java 1.1 (o forse era 1.2? Andatevelo a ricordare... io all'epoca facevo l'integralista C, perfino il C++ lo trovavo "troppo lento" -- poi ho imparato ad usarlo -- ).
Oppure a cattive esperienze con bisonti con GUI.

Le GUI in Java sono mediamente lente (anche se ormai non così lente). Uno dei problemi è la gestione dei thread. Moltissimi programmatori fanno gestire anche della logica applicativa al thread della GUI, per sostanziali semplificazioni nello sviluppo.
Questo sarebbe da evitare, in teoria. In pratica come diceva un noto sviluppatore di Twisted:

"Se hai un problema e pensi di risolverlo con i thread, ti trovi con due problemi: quello originale, e i thread".

[esses]

Parlando da utente(sia col g3 300Mhz e 256MB PC133 attuale, sia con duron 950Mhz e 512MB PC133, sia con Athlon XP 2Ghz circa e 512MB DDR), precisando che il confronto(negli anni in cui, come tutti,ho installato e disinstallato software per provare le novità) con Mono l'ho fatto col G3 e con una versione java recente(con gli altri due pc, non ho fatto il confronto con Mono, ma ho visto comunque la differenza rispetto a programmi scritti non in java) c'é un evidente lentezza di java rispetto alle applicazioni scritte con linguaggi tipo C/C++, probabilmente anche VisualBasic(nomino quelli che conosco almeno sintatticamente. Di Delphi e .Net non ho particolari conoscenze) e Mono, quest'ultimo provato solo col G3.Parlo ovviamente di applicazioni stand-alone, e non della programmazione lato internet(applet, server ecc... anche perchè non conosco le prestazioni degli altri linguaggi).
Mi si dira' sono linguaggi creati per scopi diversi, compilati in maniera diversa(bytecode o meno), alcuni interpretati. Ma io semplicemente faccio il confronto con quello che mi viene messo a disposizione come utente. Un programmatore ha a disposizione diversi linguaggi per sviluppare un software ed in generale quando posso cerco sempre un programma, che faccia una cosa che mi interessa, scritto in C/C++, poi se non c'é cerco l'alternativa che mantenga comunque buone prestazioni.
Non sono uno di quelli che sostengono il C a priori, ma vorrei che qualche programma che avessi installato mi avesse fatto cambiare idea nel corso degli anni. Ma non è cosi'. Mi aspetto una critica sul fatto che il C sia un linguaggio insicuro(secondo me la necessita' aguzza l'ingegno e ci sarebbero hacker anche senza nessun programma scritto in C/C++ e senza l'esistenza del C/C++).

[riko]

Ho seri dubbi sul fatto che tu sappia riconoscere un software scritto in python da uno scritto in C: dovresti "aprirlo" per rendertene conto. Un bel po' di programmuzzi che usi certamente su GNU/Linux *sono* scritti in Python o in Perl (o anche in Ruby). Solo che se uno non va a vedere, non se ne accorge.

Riguardo a quanto dici su Java sfondi una porta aperta: ovvero che le GUI Java non sono particolarmente prestanti. Purtroppo tu sei convinto di avere sfondato la porta "Java è lento", che è sull'altro lato dell'edificio, e l'hanno sigillata alcuni anni fa.

A parte che non so bene che JVM hai testato sul tuo G3. Sun non fa Java per Linux PPC. E non la fa nemmeno per MacOS. Per MacOS la fa Apple: ed è svariate volte meno prestante di quella Sun sotto Windows (per dire).
Eclipse di la e di qua sembrano due mondi diversi.

Se provassi per esempio certo SW in Cocoa e Java su MacOS, ti sfido a dire che sono "lenti". Ancora una volta, non te ne accorgi e devi "aprirli" per rendertene conto.
Poi se le banche e le telecom hanno deciso di basare molti nei nuovi sistemi su Java, sistemi che magari devono portare anche un milione di transazioni al secondo, forse così lento non lo è.
Un mio conoscente cui talvolta capita di lavorare con le telecom dice che sta diffondendo Twisted ( e quindi Python ) anche li.
Buona parte del successo di Google è poi dovuto a Python. Le immagini che provengono da Hubble vengono processate da software in Python.

Come dire...

Riguardo all'insicurezza del C... diciamo che il 70% delle vulnerabilità di software unix è imputabile proprio ad un singolo problema del C: ovvero la mancanza delle stringhe come tipo. Problema che non si ha in altri ambienti, ovviamente. Ormai è così e ce lo teniamo così. E quando fu creato, per come fu creato, non sarebbe stato particolarmente possibile fare le cose diversamente. Quindi amen.

[ZeuS]

Ho seri dubbi sul fatto che tu sappia riconoscere un software scritto in python da uno scritto in C: dovresti "aprirlo" per rendertene conto. Un bel po' di programmuzzi che usi certamente su GNU/Linux *sono* scritti in Python o in Perl (o anche in Ruby). Solo che se uno non va a vedere, non se ne accorge.

Io me ne accorgo perchè quando installo qualche programma python o ancora peggio perl mancano sempre librerie ...è dal nome delle librerie che mancano che mi rendo conto di quale linguaggio si è fatto uso...ma non fa ad accorparle ste librerie ? .
Perl e python ne hanno troppe invece java gira sempre senza rompere. Anche io pensavo che java fosse una merda perchè quando girava anche solo una applicazioncina il processore sfarfallava sempre al massimo....come se andasse tutto di processore. Ultimamente invece ho usato programmi in java che sono molto belli e poco esosi anche rispetto a quelli scritti in python...un esempio tra tutti Azureus...mitico!!!

[riko]

Eh... in realtà il problema è che molto sw per Python e Perl non è specifico per MacOS. Risultato non è pacchettizzato per la nostra piattaforma, e quindi ovviamente si aspetta di trovare le librerie (mentre in generale i .app che uno trova sono già imbottiti dell'occorrente).

Su Linux invece in generale usando i sistemi di pacchettizzazione tradizionale (ma io parlo per Ubuntu e/o Debian) tutte le dipendenze sono installate. Quindi se installo un sw per leggere newsfeed che usa la versione migliorata di xmllib, si installa anche quella trasparentemente, esattamente come farebbe se un programma C usasse delle librerie esterne.

Qualche problema in più con Ruby (sempre su Debian e derivate) in quanto non è gestito con altrettanta attenzione. Python invece è trattato con tutti i riguardi visto che quasi tutto il sw di gestione di Ubuntu è in Python. (Faceva parte dello scopo didattico della distro: un solo linguaggio -- e facile da imparare -- per fare tutto, in modo che fosse più facile formare amministratori etc etc ect -- si pensava per esempio ai villaggi africani ).

Java invece spesso fanno i cosidetti "giaroni", ovvero dei jar con dentro incluse tutte le librerie necessarie, che funzionano su MacOS, Win ed etc. Quindi yes, no problema di dipendenze in questo senso.

D'altra parte Python e Ruby e Perl hanno una genesi chiaramente unix. Perl è nato come alternativa a sed-awk e compagnia cantante. Ruby è nato perchè a Matz non piacevano ne Perl ne Ruby (e lui era un noto unix geek). Python ha una genesi un po' diversa.

Negli anni 70 e 80 c'era il problema di insegnare a programmare a persone senza background di informatica (fisici etc ). Persone intelligenti senza dubbio, che dovevano fare un lavoro e non potevano investire troppo in teoria informatica).

Per questi nacque ABC. C'era anche il BASIC, ma tutti sanno un pochetto quale sia la diffusa opinione (Dijkstra ci ha lasciato un paio di aforismi a riguardo -- anche se quelli su Cobol sono più divertenti, ad onor del vero).

Comunque...

Dicevo.. c'era ABC. ABC non ebbe molto successo. Van Rossum ci lavorò sopra per qualche anno. D'altra parte VR ha anche lavorato su Amoeba (un sistema operativo distribuito -- aka una figata astrale --).

Per questo sistema ha creato Python per sviluppare la gran quantità si sw che sarebbe stata da scrivere (e che a farla in C ci sarebbero voluti anni). Cosa c'entra ABC? Alcune scelte di design... da cui anche Python è molto indicato anche per non programmatori... comunque dicevo... alla fine anche Python è stato pesantemente unixizzato.

Tornando al discorso originario P/P/R sono linguaggi molto "POSIX-oriented", anche se girano ottimamente anche in ambiente Windows e hanno livelli di portabilità altissima.

Java invece è più un mondo a se (con tutti i problemi di tale mondo a se), e quindi ha dovuto fare scelte diverse. Poi anche P/P/R possono essere pacchettizzati, ma in generale tendono a volere dipendere maggiormente (solo per la pacchettizzazione) dalle strutture dell'OS su cui sono ospitati.

Per esempio Python su Windows tende a distribuire applicazioni in .exe, su MacOS in .app.

Java invece di default se la cava sempre coi .jar (e in un secondo momennto hanno creato installatori più nativi, per cui anche li .exe e .app, per dire).

[esses]

Mi dispiace che l'inizio della risposta ad un messaggio pacato, in cui ho espresso le mie opinioni di utente linux e windows di qualche annetto sottolineando che derivano dalla mia esperienza personale(e quindi ho espresso un dato soggettivo che non ho indicato come la verita' assoluta ma come una mia convinzione che non è stata modificata negli anni dalla mia esperienza) sia stato, da parte di Riko:

Ho seri dubbi sul fatto che tu sappia riconoscere un software scritto in python da uno scritto in C: dovresti "aprirlo" per rendertene conto

1)Il problema è che se scarichi programmi da sourceforge o dopo avere letto le recensioni sulle riviste linux che ci sono in edicola(saro' antiquato ma leggo ancora le riviste informatiche oltre a navigare su internet) sai il linguaggio in cui sono scritti i software che usi. Puo' ovviamente capitare di avere programmi chiusi ma su linux di solito si viene a sapere il linguaggio in cui sono scritti o le librerie che usano(recensioni su riviste o su internet).

2)Non ho nessun problema con Python, ne ho sentito molto parlare, mi incuriosisce. Ma anche se avessi davanti due software aperti(o, meglio, il loro codice sorgente), uno in Python ed uno in C/C++ non saprei riconoscere quello scritto in Python(non ho alcuna idea di questo linguaggio, nemmeno sintatticamente) se non per esclusione, riconoscendo quello scritto in C.

3)Dire si a "Java GUI è lento" e no a "Java è lento" non ha molto senso in ambiente Desktop a interfaccia grafica(a meno che non si parli di programmi server non grafici o di pagine internet che poi si poggiano su un server remoto dove si esegue codice java). Il mio terrore ogni volta che ho fatto il doppio click sul tool di sviluppo da te nominato(Eclipse) ne è la prova. Su Linux e Windows entrambi duron 950Mhz e 512MB PC133. D'altronde dovevo pensarlo prima che queste caratteristiche sono troppo, come dire, misere per provare un linguaggio di programmazione. Devo riconoscere pero' che qui sto parlando ancora di GUI(ma come utente di sistema operativo Desktop, ripeto, a me obiettivamente non interessa se il linguaggio è veloce ma non nella GUI ) e quindi passo al punto 4 in cui dico perchè lo si preferisce al C/C++.

4)Java, secondo me, è piu' sicuro, è meno ostico al primo impatto, permette totale portabilita', mi sembra elegante la sua gestione delle eccezioni. Se questo va un po' a scapito della velocita' pazienza. Se non è necessario un software particolarmente ottimizzato per una data macchina è giusto usare java. In ambito bancario, secondo me, la sicurezza e una semplicita' maggiore nella manutenzione del codice vengono prima ed e' quindi giusta la scelta di java o ,comunque, di un linguaggio con caratteristiche simili.

5)Non sono un integralista del C/C++. Ogni volta che qualcuno mi ha detto che si deve fare tutto in C solo perche' è piu' veloce , io ho sempre detto che non vale la pena, per software gestionale, di usare il C, ma VB O Delphi(+ veloci di java, secondo me). Semmai qualche dll se proprio è necessario. Motivazione: risparmio di tempo. Il ragionamento da utente pero' si ribalta: se si ha la fortuna di trovare il gestionale che serve fatto in C/C++(o il programmatore ti dice, vorrei farlo in C/C++) non vedo il motivo per non preferirlo ad altri(scritti in altri linguaggi) se soddisfa le proprie esigenze.

In sostanza, nel mio messaggio mi riferivo ad applicazioni per sistemi desktop(il classico programmino con finestra e menu e controlli nella finestra, per intenderci), forse non mi sono spiegato bene. E' corretto quanto detto da Riko, ma se è vero che, in ambito diverso da software con GUI, java ha una velocita' che ,per usi normali, non fa particolarmente rimpiangere(nemmeno nel software con GUI nel caso di hardware non molto diffuso che grazie a java ha, se quell'hardware ha una sua implementazione della jvm, la possibilita' di disporre di software che altrimenti non si penserebbe nemmeno di sviluppare in forma nativa per quella macchina)altre implementazioni, su sistemi di discreta velocita' e memoria la lentezza della GUI rende il programma lento nel suo complesso. Mi spiego meglio: se una interrogazione al database (in rete o in locale) impiega poco tempo e poi ci vuole un tempo molto maggiore, rispetto a programmi nativi, per visualizzarne il risultato in forma grafica, a me che interessa se ci vuole poco tempo per fare l'interrogazione?
Non sono un programmatore, ma un semplice appassionato, tecnicamente mi potete fare a spezzatino parlando di just in time, di garbage..., design patterns, eccetera. Ma vorrei finire con una domanda: ho sentito che il famoso portatile economico ,con manovella, da 100 dollari se non erro, avra' una CPU non potentissima(non sono sicuro ma mi sembra 500Mhz)... mumble mumble... i software scritti in java non saranno un po' lenti per questo computer?

[MazinKaesar]

Quelli sui linguaggi "interpretati" sono quasi tutti pregiudizi.

Non è vero! Ho sentito dire dal salumiere che un tipo che abita di fronte
a suo zio ha un cognato che lavora in basic e dice che è lento ( ).

[esses]

bella! mi è piaciuta

[riko]

Mi dispiace che l'inizio della risposta ad un messaggio pacato, in cui ho espresso le mie opinioni di utente linux e windows di qualche annetto sottolineando che derivano dalla mia esperienza personale(e quindi ho espresso un dato soggettivo che non ho indicato come la verita' assoluta ma come una mia convinzione che non è stata modificata negli anni dalla mia esperienza) sia stato, da parte di Riko:

Ho seri dubbi sul fatto che tu sappia riconoscere un software scritto in python da uno scritto in C: dovresti "aprirlo" per rendertene conto

Ma è così. E questo vale per te come vale per me. In Python/Ruby chiami le stesse librerie grafiche che chiami in C o in C++. Un programma in RubyGTK ha la stessa GUI di uno in C.
Da li non riesci ad accorgerti quale sia il linguaggio sottostante (mentre per esempio una GUI in Java è abbastanza riconoscibile -- anche se ad onor del vero potrebbe essere scritto anche li in Python o in Ruby con un interprete scritto in Java - risp Jython e JRuby - anche se la cosa è talmente improbabile...)

Quindi l'unico modo per renderti conto di come è scritto un software "da utente" è aprirlo. Certo, puoi andare anche su sourceforge. Io non ci avevo pensato.
Sono anni che apt-getto il software per Linux (per MacOS pure nella pagina di download quasi mai c'è scritto in cosa è scritto, anche quando sono su sf, e devi andare nella "pagina apposta").

Comunque resta il fatto: semplicemente usando un programma il linguaggio interno rimane relativamente ignoto (a meno di non andarlo a cercare, di aprirlo, appunto).

2)Non ho nessun problema con Python, ne ho sentito molto parlare, mi incuriosisce. Ma anche se avessi davanti due software aperti(o, meglio, il loro codice sorgente), uno in Python ed uno in C/C++ non saprei riconoscere quello scritto in Python(non ho alcuna idea di questo linguaggio, nemmeno sintatticamente) se non per esclusione, riconoscendo quello scritto in C.

Python è molto ben riconoscibile dai sorgenti. Lasciando stare l'esclusione, leggendo la descrizione delle sue peculiarità (l'indentazione obbligatoria per strutturare i blocchi, nessuna graffa, nessuna parola chiave per finire i blocchi) se lo vedessi lo riconosceresti.

Comunque il discorso è che generalmente quando uso sw, non lo apro

3)Dire si a "Java GUI è lento" e no a "Java è lento" non ha molto senso in ambiente Desktop a interfaccia grafica(a meno che non si parli di programmi server non grafici o di pagine internet che poi si poggiano su un server remoto dove si esegue codice java).

Beh, invece ha un senso. Quello che io ho (impropriamente) chiamato Java GUI in realtà è Swing, Awt e il toolkit di Eclipse (anche se questo è più snello, IIRC). Su una macchina windows ragionevolmente recente -- tipo il mio PC di 4 o 5 anni fa -- non sono in genere oltremodo pesanti. Su Linux lo ignoro, di solito mi rompo le palline e tengo la JVM di GNU, e per sviluppare Emacs, quindi non so dirti come siano le performance.

Certo, sono sensibilmente più pesanti che una cossa scritta con MFC, per dire. O con Delphi. Certo. Ma per esempio se faccio una GUI Java con Cocoa (su MacOS X) non sarà lenta. Non è il linguaggio, è la libreria grafica.

Sarebbe interessante provare i binding GTK per Java. Purtroppo io GTK non lo guardo dalla 1.4 e non ho tanto tempo di aggiornarmi.

Il mio terrore ogni volta che ho fatto il doppio click sul tool di sviluppo da te nominato(Eclipse) ne è la prova. Su Linux e Windows entrambi duron 950Mhz e 512MB PC133. D'altronde dovevo pensarlo prima che queste caratteristiche sono troppo, come dire, misere per provare un linguaggio di programmazione

Non è questione di linguaggio di programmazione, lo hai detto tu stesso. È questione di Eclipse. Io su Windows quando lavoro in Java generalmente uso UltraEdit Studio (caro, ma li vale).
Poi nessuno ti vieta di usare gvim/Emacs. Io sono sempre stato moderatamente scettico verso gli IDE... dicevo comunque, il problema non è in cosa programmi, ma cosa usi per programmare.

Se usi Eclipse + il plugin per il C e programmi appunto in C, sei pesante uguale.

4)Java, secondo me, è piu' sicuro,

Si.

è meno ostico al primo impatto,

Passo, per me è il contrario... ma io il primo impatto con il C lo ho avuto a 14 anni.

permette totale portabilita'

Nei sogni di Gosling ... purtroppo sono madonne anche li. Diciamo che aiuta.


[quote]
mi sembra elegante la sua gestione delle eccezioni.
[/quote]

Beh, potere gestire le eccezioni fa spesso risparmiare un sacco di codice (o per lo meno separare chiaramente la logica standard da quella in caso di comportamento insolito).
In particolare Java ha la peculiarità che le eccezioni cosidette "checked" (la maggior parte) debbano essere dichiarate nei metodi (se possono uscirne). Personalmente la cosa mi ha mostrato nuove vie nell'arte di bestemmiare, ma a parte questo immagino possa essere anche comodo.

Diciamo che i Javisti sono divisi sul punto (io con tutte le critiche che muovo a Java ogni volta che sono stuzzicato a riguardo questa me la risparmio.

Se questo va un po' a scapito della velocita' pazienza. Se non è necessario un software particolarmente ottimizzato per una data macchina è giusto usare java.

In ambito bancario, secondo me, la sicurezza e una semplicita' maggiore nella manutenzione del codice vengono prima ed e' quindi giusta la scelta di java o ,comunque, di un linguaggio con caratteristiche simili.

In realtà per loro le prestazioni sono assolutamente critiche. Non potrebbero scegliere una piattaforma che non fosse oltremodo veloce. Semplicemente non interessano le GUI. Quello che deve essere veloce è il backend ( e li Java non si comporta peggio in media di altre piattaforme).

5)Non sono un integralista del C/C++. Ogni volta che qualcuno mi ha detto che si deve fare tutto in C solo perche' è piu' veloce , io ho sempre detto che non vale la pena, per software gestionale, di usare il C, ma VB O Delphi(+ veloci di java, secondo me). Semmai qualche dll se proprio è necessario. Motivazione: risparmio di tempo

Il ragionamento da utente pero' si ribalta: se si ha la fortuna di trovare il gestionale che serve fatto in C/C++(o il programmatore ti dice, vorrei farlo in C/C++) non vedo il motivo per non preferirlo ad altri(scritti in altri linguaggi) se soddisfa le proprie esigenze.

Ribadisco... per queste applicazioni usare C/C++ non ti porta vantaggi. Creare un bottone con una chiamata Python o con una C ha un costo trascurabile rispetto a creare il bottone stesso.

Buona parte dei linguaggi interpretati di genesi Unix in effetti chiamano *tantissimo* codice C, e non vedo perchè il minimo costo aggiuntivo di gestire uno stack di chiamata appena più complesso dovrebbe dare questi problemi (problemi che sulla mia esperienza in effetti non si manifestano).

Usavo applicazioni scritte in Python (con GUI) già su un G3 a 233 MHz, e fin da allora le differenze non erano percepibili (mentre invece KDE, in C++, era *molto* più pesante di Gnome... ma più che per ragioni di linguaggio, ancora una volta per ragioni di libreria).

Ma vorrei finire con una domanda: ho sentito che il famoso portatile economico ,con manovella, da 100 dollari se non erro, avra' una CPU non potentissima(non sono sicuro ma mi sembra 500Mhz)... mumble mumble... i software scritti in java non saranno un po' lenti per questo computer?

Ribadisco, non è Java. Semmai è Swing. Java gira anche sul mio cellulare, che va bene se ha un processore da 50 MHz.

[MazinKaesar]

è meno ostico al primo impatto,

Passo, per me è il contrario... ma io il primo impatto con il C lo ho avuto a 14 anni.

Idem, solo che io ho cominciato col Pascal (e non ridete! )

[riko]

Idem, solo che io ho cominciato col Pascal (e non ridete! )

Non c'e' nulla da ridere. Adessi Pascak e' diciamo un po' datato... ma vent'anni fa su un computer home le scelte erano BASIC o Pascal, in pratica. E Pascal era senza dubbio la scelta migliore.

Certo, c'era anche Rexx. E pure C "tecnicamente" esisteva, anche se aveva un grado di diffusione e supporto (per i "non programmatori") decisamente peggiore.

Il tutto IMHO, eh...

Poi io ho avuto la sfortuna di cominciare con il BASIC. Per l'Apple ][ mio padre non aveva giochi, e cosi' me li scrissi io. In parte la storia poi si e' ripetuta con il mio primo Mac.

I giochi li c'erano. Ma i venditori Mac qua in zona come prior exposure a qualcosa di tecnologico avranno potuto al piu' elencare una mungitrice elettrica... figurarsi fare un ordine in america.

Faccemmo anche quello... e dopo un mese e mezzo mi arrivo' la prima vversione di Sim City!

[MazinKaesar]

Allora, è finito l'Euochocolate (yum yum!!!) e mi è passato il mal di pancia
(groan!!!!). Torniamo alla compilazione dell'eterm. Mi piacerebbe,quando
come e perchè trovo un poco di tempo, ripercorrere insieme l'epopea
vissuta in ufficio.

Stay tuned ...

[riko]

Vai!

[MazinKaesar]

Per la serie: Sono Un Cretino [TM]

Se facevo attenzione ai messaggi che mi diceva l'eterm mi accorgevo
che era solo un problema di permessi

Bastava assegnare il suid a eterm e assegnargli come gruppo quello di root,
e ti indirizza la stampa anche nel ventilatore usb...

Altro che MazinKaesar, cambio nick in MazinLamer

[riko]

LOL