Newsgroup: it.comp.os.linux.iniziare
Titolo: Linux e Unix

Secondo voi e' possibile far girare un programma di Linux su un sistema Unix 
e viceversa oppure e' impossibile? 

 Unix e viceversa oppure e' impossibile? 
A quanto ne so, Linux e` POSIX-compatible come la maggior parte degli
Unix, solo che non puo` chiamarsi "Unix" poiche` e` un marchio
registrato. Quindi, immagino di si`. Al limite, con piccole modifiche. E
se il programma vien scritto bene la portabilita` si riduce a poche
linee di modifica del codice.
Ciao,
M.

 question non sia in Java.
O in Python (non so Ruby su quante piattaforme giri)
-- 
il Vide - ICQ #5301833
http://www.heavy-metal.it
Bebe, danza, sueña siente que el viento ha sido echo para ti
NP: Nulla

 e viceversa oppure e' impossibile?
Le probabilità di riuscita sono abbastanza alte, ma non c'è nulla di
certo. I sistemi sono molto simili, ma tuttavia sono differenti.
Da quel che ne so, i sistemi differiscono in special modo per:
1) libc
2) shared libraries (ovvero alcuni sistemi le supportano, altri no)
3) architettura del sistema
per quanto riguarda il punto 3, ovvero cercare di far girare applicativi
per cpu sparc/alpha/mips su intel, l'unico modo è ricorrere ad una
virtual machine come 'qemu' ma per quanto lo ho provato ne ho solo visto
una modalità che crea una macchina virtuale su cui devi installare
sistema operativo e programmi.
quindi non è per nulla integrato al sistema operativo "principale".
per i punti 1 e 2 invece esistono da lungo tempo dei software che si fanno
carico di nascondere le differenze del sistema all'applicativo "straniero"
e rendergli disponibile un ambiente a lui familiare.
iBCS è uno di questi e credo che esista da più di 10 anni, per cui è da
considerarsi decisamente stabile.
http://sourceforge.net/projects/ibcs
un altro è questo, che ho scoperto tramite la pagina di iBCS
http://sourceforge.net/projects/linux-abi
conosco i due software solo di nome, in quanto non ho mai avuto necessità
di far girare applicativi di sistemi *nix su linux.
buon lavoro!
ciao
gl :)

 gl :)
Grazie a tutti :-)
mi avete chiarito  le idee 

 quindi non è per nulla integrato al sistema operativo "principale".
Con la versione "usermode" (non so come si chiami) lunedi' ci ho
recuperato la macchina di un pazzo che non voleva perdere l'uptime
(sul portatile!) e sulla quale aveva "erroneamente" cancellato
/lib/
ld-2.3.2.so
Abbiamo usato dei binari per powerpc che aveva sul computer e quemu
(che aveva compilato staticamente) per eseguirli. A botte di qemu -L
/libdir binario-ppc abbiamo scaricato il file e messo al posto giusto.
dopo si e' installato busybox (sempre troppo tardi)
.a.
-- 
Il mattino ha l'oro in bocca. Il MATTino ha l'OrO In bOcca.
i lma tt ino ha l'o roin bocc a.ilmattinohal'oroinbocca. il ma tt in
oh al' or oi nb oc ca. il matti noha l'oroinbocca. IL MATtiNO Ha l'ORO
InBOCCa. I l m a t t i n o  h a l' o r o i n b o c c a . ilmattinohal'oroin
BoCcA. iLmAtTiNoHaL'oRoInBoCcA.

 /libdir binario-ppc abbiamo scaricato il file e messo al posto giusto.
mi son fermato a guardare solo il man qemu e non avevo visto questa
opzione. allora qemu è proprio un bel pezzo di software! :)
ciao!
gl :)

 opzione. allora qemu è proprio un bel pezzo di software! :)
In effetti qemu e' il binario per la virtual machine, poi puoi anche
compilare qemu-i386 qemu-ppc qemu-sparc qemu-arm che servono per
tradurre solo il binario. Per funzionare ovviamente i programmi devi
avere le librerie per quell'architettura...
Ci feci girare acrobat reader e gflashplayer sull'iBook con quel
sistema...


 script.
La differenza però da un bytecode java non è poi così sostanziale, per la
macchina.


 script.
IMHO il concetto di "programma" va oltre quello di "eseguibile in codice
macchina". In informatica tipicamente questa distinzione non esiste (non
a livello di "programma", nel senso che "programma" e` un concetto piu`
esteso)
Anche perche` gli ambienti da te elencati, sono molto differenti fra
loro.
python per esempio bytecompila il codice e poi lo esegue, ma nulla ti
vieta di dare in giro il bytecode. Non solo, ma nulla vieta di usare
tools tipo py2exe per creare eseguibili che *non* dipendono piu`
dall'interprete.
Simili discorsi immagino si possano fare anche per Perl e Ruby. Di Perl
ricordo qualcosa quando lo usavo, ma alla fine siccome lo usavo solo in
ambito *nix potevo benissimo tenere il programma cosi` come era.
bash che io sappia invece viene proprio interpretato in senso
tradizionale.
Java pure lui e` solo byte-compilato, anche se non ha la comodita` della
compilazione automatica in stile python.
Pensa poi al Prolog. Totalmente interpretato (per lo meno nelle
implementazioni che conosco io) eppure usato per compiti parecchio
raffinati (poi a me non fa impazzire, ma questo e` un altro discorso).
E il Lisp? Esistono sia compilatori che interpreti. Un "coso" in Lisp e`
un programma o no?
Se invece vuoi mettere la distinzione sul *compito* del programma,
ovvero chiami programma un oggetto che fa qualcosa di "grosso", progetti
importanti sono stati sviluppati in un po' tutti i linguaggi.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto
pretenderanno che tu torni indietro/e ti costringeranno a partorire per
poi chiamarlo figlio della colpa / e tu una Maddalena da pentire

 compilazione automatica in stile python.
Java è un linguaggio di programmazione.
Il JDK della Sun compila il codice sorgente solo in forma di bytecode.
Il GCJ (parte del compilatore GCC) compila da sorgente in bytecode, da
sorgente in codice nativo, da bytecode in codice nativo.
ciao
gl :)

 sorgente in codice nativo, da bytecode in codice nativo.
Avevo sentito parlarne... ma fa anche swing? L'ultima volta che ne avevo
sentito parlare mi pareva di no...
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 sentito parlare mi pareva di no...
il compilatore fa solo la sua parte, ovvero compila. :)
come la libreria libc per il linguaggio C e la libstdc++ per il C++, anche
Java ha delle librerie di riferimento, che non hanno nulla a che fare col
compilatore.
in questo caso, la libreria di riferimento è lo GNU Classpath.
in realtà c'era una libreria specifica di GCJ (la libcgj) ma la
stanno unificando con il classpath perché questo è utilizzato da più
JVM open source come Kaffe e SableVM (anche se ogni VM tiene una sua copia
del classpath per le patch specifiche) e quindi ha più supporto dagli
sviluppatori.
lo GNU Classpath è molto avanti, ma ancora lontano da essere completo.
c'è molto Swing dentro il Classpath, e credo quasi tutto AWT però
mancano ancora molti metodi delle classi.
da notare però una cosa, il GIJ (versione Just in Time del GCJ) è in
grado di eseguire Eclipse (che si appoggia a librerie SWT già presenti) e
anche di funzionare (con i limiti di cui si parlava sopra) come plugin per
Mozilla.
Nel mondo open source ciò che riguarda Java gira intorno a IBM e se IBM
dice SWT, lo sviluppo del Classpath su Swing sarà l'ultima cosa che
staranno a guardare. Suppongo.
ciao!
gl :)

 lo GNU Classpath č molto avanti, ma ancora lontano da essere completo.
Usabile in produzione? Da quanto dici direi di no...
(Usabile vuole dire da una persona assennata...)
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 (Usabile vuole dire da una persona assennata...)
ecco cosa dice 
http://www.gnu.org/software/classpath/classpath.html
Current snapshot releases have implementations for the following packages
(and some subpackages) java.applet, java.awt, java.beans, 
java.io
,
java.lang, java.math, 
java.net
, java.rmi, java.security, java.sql,
java.text, java.util, java.util.jar, java.util.zip. Not all classes and
methods are implemented yet, but most are. many of the implemented classes
are already up to the 1.2 API spec. Some are already compliant with the
1.3 and 1.4 API specification (there are preliminary implementations of
java.nio and javax.swing).
come vedi c'è buona parte delle classi, ma non tutti i metodi.
leggevo che si parla di un 90-95% dei metodi già implementati
completamente (quindi non dei semplici stub)
tempo fa avevo provato a compilare qualcosa in AWT e Swing tanto per
provare, ma mi son fermato poco oltre le prove perché di Swing c'è
veramente poco.
Insomma, tu vuoi sapere "poco quanto"... allora guarda qui:
http://sablevm.org/screenshot.html
attualmente non ha senso usare niente altro che il JDK 1.5.0_02 ufficiale.
se invece hai una piattaforma non supportata può valer la pena di provare
una JVM open con il classpath.
in particolare, qualcuno è recentemente riuscito a far funzionare tomcat4
con sablevm su Alpha, dove HPaq ha smesso di distribuire, oppure ha
nascosto molto bene, il JDK che era in distribuzione per alphalinux.
http://gadek.debian.net/SableVM-Alpha/
ciao!
gl :)