Newsgroup: it.comp.os.dibattiti
Titolo: Cos'e` Unix?

 web, mail, proxy e tutto il resto, non per cuBase..
Permettimi di dissentire: Unix nasce come ambiente di sviluppo,
il networking e` cosa recente.
Quando K&R&P&T&al. hanno fatto il primo Unix era perche` si erano
stufati
del loro precedente OS (Multics) e da bravi programmatori si sono fatti
un OS, con tutti i tool, per poter programmare e, in generale,
sviluppare
applicativi & applicazioni, non ultime quelle musicali, vedi CSound.
Se credi che Unix == TCP/IP sbagli di grosso, questa e` solo una delle
tante potenzialita` di Unix. Il punto chiave e` nella filosofia delle 
scatole cinesi di Unix, i building blocks. Per questo dico (scrivo) che
a volte (non sempre) e` meglio perdere il tempo a scriversi il SW (su
Unix)
piuttosto che cercarlo come disperati per giorni in rete.
bye,
--
  Piergiorgio Sartor
  Sony International (Europe) GmbH
  European R&D Stuttgart
  Advanced TV Group              Tel.: 
++49-(0)711-5858-525
  Stuttgart Technology Center    FAX: 
++49-(0)711-5858-199
  Stuttgarter Strasse 106        e-mail: 
sar...@sony.de
  D-70736 Fellbach, Germany

 scatole cinesi di Unix, i building blocks. Per questo dico (scrivo) che
Non dico questo, dico che lo fa meglio di altri e cio' e' innegabile. Cosi'
come e' vero che la sua filosofia si basa sull'uso di n programmi piccoli
ognuno dei quali fa bene una cosa invece di uno grosso che cerca di farne
n e le fa male (vedi gli innumerevoli filtri che permettono di fare di tutto)
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
* Mettete Blisset & Max_Adamo nel vostro killfile ! *

 n e le fa male (vedi gli innumerevoli filtri che permettono di fare di tutto)
Esatto! I filtri! La prima regola di Unix (la seconda e` avere
tutti file di testo ASCII)!
Comunque Unix fa meglio di altri tante cose...
Ritornando al discorso musica: nulla impedisce l'uso di Unix
per la musica.
La mia tesi riguardava la musica ed e` stata sviluppata tutta sotto
Unix.
Il SW CSound e` un classico esempio di unix-tool.
In generale quello che succede e` che la maggior parte della gente
si "accontenta" dei SW commerciali e non pensa che sia possibile
scriversi
il SW da se (magari migliore), lo considera inumano e complesso.
Questo perche` sono abituati con altri OS che sono realmente complicati,
OS con i quali e` impossibile fare qualcosa che non sia stato precotto
dal produttore.
Da qui il mio motivo di insistere su: scrivetevelo da voi il vostro SW,
qualunque esso sia, soprattutto se deve girare su Linux.
Per Pierluigi in particolare: partecipi all'IOCCC 1999?


 Per Pierluigi in particolare: partecipi all'IOCCC 1999?
Lo farei, ma dovrei rinfrescare il mio C :-)


 Da qui il mio motivo di insistere su: scrivetevelo da voi il vostro SW, qualunque >esso sia, soprattutto se deve girare su Linux.
Uhm ... uhm ... uhm ... (mano al mento, fronte corrugata da profonti
solchi e occhi protesi al monitor intenti nella lettura del post n.d.n.)
Ma a chi ti rivolgi quando dici di non accontentarsi del SW commerciale
ed insisti dicendo di scriverselo da soli ???
Forse il C sotto Linux e' diverso (leggi piu' facile) da quello sotto
WinXX ??
Ti riferisci alle varieta' librerie ??
Spiegati meglio! 
Ciao
Francesco

 WinXX ??
Si.
Non tanto il C di suo, ma l'ambiente che ci sta attorno, e` molto
piu` facile. Inoltre non e` necessario fare tutto in C.
Ad es. il perl e` usatissimo per fare CGI.
E` difficile spiegare, il concetto base e` quello dei filtri o delle
scatole cinesi.
Ad. es tu puoi fare un SW composto da piu` linguaggi, a seconda
della facilita` di fare le cose in ognuno di essi.
Puoi fare un SW che composto da piu` pezzi differenti, anche
sviluppati da diverse persone.
E` possibile fare un SW senza interfaccia grafica ed aggiungerla
successivamente, con un altro linguaggio.
Il livello di flessibilita` e` elevatissimo.
I tool di sviluppo sono potentissimi si integrano uno
nell'altro senza problemi, questo perche` tutto e` gestito
in modo testo ASCII.
Se si scrive un tool che rispetti la filosofia stdin-stdout
(facile per altro) questo si integrera` nel mondo gia`
esistente senza problemi.
Ritornando alla domanda: "il C sotto Linux e` diverso?", sembra
che tu pensi che solo il C sia utile per programmare, questo e` gia`
un limite che ti sei imposto a priori (c'e` anche il FORTRAN :-)),
ma che non ha riscontro in Unix.
Il C si usa solo se sono necessarie particolari prestazioni.
Un altro esempio e` il filtro per la posta elettronica:
qualora si volesse scrivere un risponditore automatico
o filtro o, sotto Unix, questo sarebbe facilissimo.
Si scrive un SW che prende il testo come stdin, lo elabora,
e produce un qualche output (risposta, logging oppure esegue
la e-mail come lista comandi...).
Nota che non si pone nessuna limitazione a cosa fare con quel testo.
La stessa operazione su OS commerciali (non Unix) e`, o estremamente
facile, ma limitata a pochissime cose, oppure estremamente difficile, in
alcuni casi impossibile.
Chiaramente chi usa il PC per navigare e scaricare immagini
di gentili donzelli in vestiti succinti non ha bisogno
di Unix, forse... (pensadoci bene, pero`...).


 qualunque esso sia, soprattutto se deve girare su Linux.
Ragazzi, ragazzi, state dimenticando una cosa: la maggior parte della
gente, la' fuori, non SA programmare, non VUOLE programmare, non
GLIENE FREGA UN CAZZO di programmare, vuole che i bei tipini che
studiano nelle oscure aule delle universita' gli dia la pappa pronta!
Voi sapete programmare, chi piu' chi meno, e' una vostra passione,
avete tempo da passarci, ci avete magari anche studiato sopra; ma NON
POTETE pretendere che ognuno si faccia il suo software. E' cosi' che
funziona il mondo moderno, altrimenti torniamo al medioevo. Anzi no,
anche nel medioevo si faceva gia' cosi': c'era il panettiere, c'era il
calzolaio, c'era il fabbro, c'era il falegname; e il panettiere non
sapeva fare scarpe, armi o tavoli, e il calzolaio non sapeva fare
pane, armi o tavoli, e il fabbro non sapeva fare pane, scarpe o
tavoli, e il falegname non sapeva fare pane, scarpe o armi; ognuno
faceva quello che sapeva fare e lo scambiava con altre cose, che non
poteva o non sapeva fare. Oggi invece ci sono meccanici, avvocati,
architetti, medici... e programmatori.
Ragazzi, se il vostro meccanico vi dicesse "ma perche' vuoi
un'automobile commerciale? fattene una da te" voi cosa gli
rispondereste?
E non trovate scuse del tipo: "non posso costruirmi un'auto perche'
non ho gli attrezzi, mentre il software se lo puo' scrivere chiunque
visto che i tool di sviluppo sono gratis" perche' se voi aveste gli
attrezzi non potreste lo stesso costruirvela, l'auto, visto che non
avete le conoscenze necessarie, cosi' come tutti gli accessori di cui
avete bisogno.
Quindi, ragazzi, se qualcuno vuole pagare qualcun altro affinche' gli
faccia un programma, bene, ha tutto il mio rispetto, mica lo sfotto
perche' non se lo fa da se' (in particolar modo se vuole pagare ME per
quel programma...)
Spero di aver chiarito il mio punto di vista e scusate per i termini.
--
by Gabriele Biffi
gbi...@usa.net
 - ICQ 5619491
http://www.rete039.it/civis/gbiffi/
"Il Pensiero genera l'Eresia; l'Eresia genera il Castigo." - WarHammer

 tutti file di testo ASCII)!
Ecco, un'altra cosa.
Perche' i file di testo devono per forza essere ASCII, limitato a 128
caratteri (anzi, 96, visto che i primi 32 sono di controllo)? Al
giorno d'oggi i computer sono diffusi in tutto il pianeta, mica solo
in america o in paesi anglofoni. Gia' in questo post, per essere
sicuro della compatibilita', devo usare gli apostrofi al posto delle
lettere accentate che si trovano proprio sotto. E quando devo scrivere
qualcosa in cirillico (seriamente) devo fare un casino assurdo, anche
sotto Winzozz.
Non so voi, ma io tifo per Unicode e abbasso ASCII.

 quel programma...)
Il problema non e`: "pago qualcuno (te?) per fare un SW",
ma invece: "vado in giro a cercare se qualcuno ha fatto qualcosa
che mi puo` interesare e se non e` freeware lo pirato".
In generale non biasimo nessuno per usare SW non autoscostruito,
ma biasimo quelli che vanno in giro dicendo: "sono COSTRETTO ad
usare xyz perche` solo li ho il SW che mi serve", oppure: "uso
xyz perche` c'e` solo quello, anche se non va proprio bene".
Il che e` l'esatto opposto di quello che hai appena scritto,
non "scelgo, compro il sw", ma "sono costretto al SW".
Come se dicessi: ho una macchina abc, non va bene, ma sono
costretto ad usare quella perche` non ci sono altre scelte.


 Non so voi, ma io tifo per Unicode e abbasso ASCII.
Su questo potrei essere d'accordo.
Il senso era che essendo testi (ASCII in particolare) sono leggibili
da esseri umani.
Sotto Unix si cerca di mantenere tutto a livello di testo,
cosi` i tool di sviluppo sono interoperabili, il file sono "leggibili",
il livello di standardizzazione e` elevato.
Su altri OS i file di configurazione sono binari, con il risultato che:
non sono leggibili, se non con un apposito SW
non sono editabili, se non con un apposito SW
se si "rovinano" (succede) sono difficilmente recuperabili
non sono assolutamente riscrivibili da zero (caso estremo)
sono proprietari e nessuno sa cosa c'e` dentro realmente
Riguardo unicode: sono d'accordo che ASCII e` un po' limitativo,
ma forse proprio qui sta la sua forza, difficilmente si possono fare
voli pindarici (incomprensibili) per scrivere un file di
configurazione, cosi` ognuno deve seguire una retta via...
Per i testi letterari, ovviamente, unicode e` meglio di ASCII.
Hai provato LaTeX? Semplifica (?) l'uso degli accenti e
dovrebbe avere i font cirillici, credo.


 da tale SW.
...ed io che non sono soddisfatto del SW commerciale e non sono capace 
di programmare in nessun linguaggio e non voglio passare le notti a 
studiare una cosa che non mi interessa perche' nella vita faccio
altro ???
Dal tuo discorso io UTONTO COMUNIS SED PECUNIARIUS decido che, visto
la mia incapacita' a programmare, di trovare qualcuno che lo faccia 
al mio posto, magari il tutto gia' pronto in un bel pacchettino colorato
con la scritta per WinXX e contribuisco con il mio denaro ad ingrassare
il porcellino americano BG.
Ovviamente non devo rompere al prossimo se quello che acquisto non vale
quello che ho speso, se compaiono schermate blu e se il mio fegato
aumenta di dimensioni per i conflitti,malfunzionamenti, etc.
Ciao 
Francesco

 aumenta di dimensioni per i conflitti,malfunzionamenti, etc.
Non devi "rompere" dicendo: "che schifo, ma non avevo scelta",
la scelta c'e`, forse e` l'unico caso, il SW, dove si puo` realmente
scegliere. Altri mercati sono un po' piu` chiusi (vedi le CPU).


Quanto hai affermato e' pura idiozia.
Vale la pena di fare un paio di considerazione sul Software e su come si
sia evoluto nel mercato.
All'alba dei tempi si era a livello di arte: chiunque scriveva un
programma ne era anche l'utilizzatore (quello che appunto tu affermi
dover essere la regola).
Poi si e' passati a livello di artigianato: l'utente finale differiva
dal programmatore.
Infine, e parlo del presente, si e' passati a livello industriale.
Questo significa che non conta piu' il prodotto in se' ma come lo si
produce.
Il programmatore e' in genere l'ultima ruota del carro: il suo ingegnere
del software gli da' le specifiche a basso livello e lui le realizza
senza esser tenuto a prendere alcuna decisione su parti che non gli
competono.
Saranno altri poi a fare il testing e la validazione, a decidere se il
suo pezzo puo' andar bene o se deve tornare a sgobbare.
Alla fine cio' che ne esce e' un prodotto a scatola chiusa che deve fare
quanto impone la specifica generale del progetto, stabilita magari
direttamente nel contratto tra chi produce e chi acquista.
Questo e' quello che si chiama un modo di lavorare serio.
Ed il cliente ha tutto il diritto di ricevere quello che vuole, di non
dover essere tenuto a fare altro che lanciare il programma.
Non deve sapere come quel programma e' fatto all'interno, non deve
farselo da se', deve solo usarlo.
Fossi in te mi sveglierei, questi sono gli anni '90 e quella del SW e'
un'industria come quella dell'auto o dell'elettronica di consumo.
Certo, a differenza che nelle altre industrie c'e' una maggiore
quantita' di disonesti (chi promette features che poi non riesce a
mantenere) e una ancor maggiore quantita' di polli (chi piglia come una
fatalita' ineluttabile che le cose non funzionino o funzionino male).
Cio' non toglie che quanto tu prospetti sia l'opposto dell'informatica
moderna.
Ciao,
     Antonio

 ... omissis ...
Tutto vero, tutto giusto, peccato che ci sia gente che compra (o pirata)
SW
e poi si lamenta che non funziona, che fa schifo, etc.
Allora, se tu avessi letto bene, io dico: perche` vi lamentate? Se il
prodotto che avete comprato (?) non vi soddisfa, se non trovate
alternative
valide, avete sempre la possibilita` di farverlo da voi.
Una CPU NON PUO` essere fatta in casa, ma un SW si.
Io non prospetto che ognuno si faccia il SW per conto suo, ripeto
impara a leggere, io dico che non si hanno motivi di lamentarsi,
soprattutto quando si pretende il SW gratis (freeware o pirateware
che sia).
Spero che il reply sia giusto.


Non so voi, ma io tifo per Unicode e abbasso ASCII.
Io sono dall'altra parte dello stadio ;-)
Bonf
P.S.
Hai mai guardato da dentro qualche eseguibile di windows ?

 avete bisogno.
E io aggiungo: e il mondo sarebbe pieno di software scritto veramente male.
-- 
Fabrizio Di Giuseppe
mailto:
fabr...@iride.com
http://www.iride.com/fabrizio/

 E io aggiungo: e il mondo sarebbe pieno di software scritto veramente male.
Si potrebbe replicare che per fare SW "scritto veramente male" ci
pensano
gia` grossi colossi industriali... :-)


 da tale SW.
Non puoi dire che tutto il sofware commerciale fa schifo e che c'e'
sempre un corrispondente software free che fa il lavoro meglio! Questo no!


 sempre un corrispondente software free che fa il lavoro meglio! Questo no!
Non mi pare di aver scritto questo...
Mi piace l'intelligenza con cui la gente legge i miei post... :-)
(scusa, non ho saputo resistere).


 gia` grossi colossi industriali... :-)
E gia' quello basta.
Comunque, hai presente la sindrome piu' comune degli Italiani? Tutti gli
Italiani hanno idee da Presidente del Consiglio, Presidente della
Repubblica ed allenatore della nazionale. Peccato che a ricoprire queste
cariche siano solo in tre. Se tutti quelli che usano un computer
facessero i programmatori... il software buono (free o commerciale non
importa) affogherebbe in un mare di... indovina?


 importa) affogherebbe in un mare di... indovina?
Non credo, c'e` un certo effetto Darwin per il software NON spinto
dal marketing: i migliori sopravvivono, le schifezze spariscono.
Il problema, ripeto per n+1 esima volta, non e` farsi TUTTO il SW
in casa, ad oltranza.
Bensi`: se non trovo il SW che mi serve, invece di piangere,
mi rimbocco le maniche e me lo scrivo, se poi questo SW serve ad altri
ed e`
buono, di sicuro diventa di successo, altrimenti sparisce.
E` chiaro che se il SW esiste gia`, ed e` buono, usero` quello.
Supponiamo, pero`, che le SW house riescano a fare la protezione finale,
non piu` SW piratato, credi che non sarebbe necessario scriversi il SW
da soli?
Tutti usano word, facile, rapido, spesso a costo zero, ma se cosi` non
fosse quanta gente spenderebbe denaro per comprarlo?
Oppure non si usa piu` il computer... Si torna alla macchina da
scrivere, poi sarei io quello antico...
Invece, dato che la possibilita` c'e`, se il SW manca lo scrivo da me,
solo se manca, pero`, e` chiaro questo.


Antonio Marullo (
anma...@iol.it
) wrote:
[ snip ]
: All'alba dei tempi si era a livello di arte: chiunque scriveva un
: programma ne era anche l'utilizzatore (quello che appunto tu affermi
: dover essere la regola).
Arte ?
[ snip ]
: Infine, e parlo del presente, si e' passati a livello industriale.
: Questo significa che non conta piu' il prodotto in se' ma come lo si
: produce.
Cioe' ?
[ snip ]
: Questo e' quello che si chiama un modo di lavorare serio.
La serieta' non c'entra nulla.
[ snip ]
: Fossi in te mi sveglierei, questi sono gli anni '90 e quella del SW e'
: un'industria come quella dell'auto o dell'elettronica di consumo.
Ma...questa e' una storia che gira da un po' di tempo, pero' non mi
sembra che sia cosi' simile, ad esempio, all'elettronica di consumo: 
potrebbe diventarlo se ci fosse un SO standardizzato che gira su un 
HW standardizzato, e il mercato fosse principalmente sui prodotti 
software. 
In questo caso ad un ipotetico cliente basterebbe comprare il SW dal 
rivenditore che preferisce, sicuro che comunque girererebbe sul suo 
PC.
E...no, non e' la situazione attuale del mondo Win* ;), lo potrebbe
diventare in futuro, forse con qualcosa di diverso (Java ?).
: Certo, a differenza che nelle altre industrie c'e' una maggiore
: quantita' di disonesti (chi promette features che poi non riesce a
: mantenere) e una ancor maggiore quantita' di polli (chi piglia come una
: fatalita' ineluttabile che le cose non funzionino o funzionino male).
Appunto, il mercato (di massa) e' ancora "immaturo" da questo punto di 
vista: le caratteristiche 'di base' di un prodotto SW non comprendono 
neanche il corretto funzionamento...
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

Son tutte belle parole.
Ma rifletto su una cosa:
Ma Unix ( e meglio ancora Linux) č realmente un oggetto
al quale possa essere applicato un metodo industriale
canonico?
Io penso di no. Le radici e i retaggio culturale dei fautori di Unix e di
Linux č in antitesi con tutto quello che l'industria attuale rappresente.
Quindi su posizioni di partenza difficilmente conciliabili.
Ma č una mia personale opinione.
Saluti.

 da tale SW.
Non mi pare lasci spazio ad altrei interpretazioni, visto che non citi
affatto una terza categoria.


 affatto una terza categoria.
E` necessario?
Scherzi a parte, mi pare si leggano le news un po' troppo in
fretta e si risponda ancor piu` rapidamente.
Perche` non lo hai chiesto (se c'e` una terza categoria), invece di
rispondere con affermazioni "forti".
Anche il tono di questo tuo reply (vedi sopra "intelligentone")
mi pare un po' aggressivo, o sbaglio?
Oppure bisogna mettere :-) su ogni riga, a scanso di equivoci?
Questo non c'entra nulla con il discorso precedente, scusate.


In un messaggio del Fri, 12 Mar 1999 15:06:49 +0100 "Gabriele Del Giovine" scriveva:



Come al solito postuma di una bella fumata di un cannone...


Come al solito postuma di una bella fumata di un cannone...
Ma almeno hai capito quello che ho detto?
Unix (e Linux) non sono controllabili dall'Industria, perchè
sono fuori dagli schemi dell'Industria intesa nel senso deleterio
della parola (puoi leggere CAPITALISMO). E  questo è un bene.
Il dubbio mi viene guardando allo specchio il nome di colui
che viene indicato come il  fautore di tutto questo.
LINUS  diventa SUNIL (SUN IL)
Saluti.

gbi...@usa.net
 wrote:
 >Perche' i file di testo devono per forza essere ASCII, limitato a 128
 >caratteri (anzi, 96, visto che i primi 32 sono di controllo)? Al
Perche` ci sono newsreader schifosi tipo free agent che non gestiscono
MIME.
 >lettere accentate che si trovano proprio sotto. E quando devo scrivere
 >qualcosa in cirillico (seriamente) devo fare un casino assurdo, anche
 >sotto Winzozz.
E` un peccato, perche` con emacs e` molto semplice... Anche scrivere in
giapponese, cinese o coreano.
 >Non so voi, ma io tifo per Unicode e abbasso ASCII.
Proponilo ai tuoi corrispondenti russi e guarda cosa ti rispondono...
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | > Mettete 
maxa...@tin.it
 nel vostro killfile (Pub. progresso) <

MIGLIORI dei meccanici "specializzati", quindi...
Per amore della precisione: Gabriele parlava di *costruirsi* un'auto
("fattene una da te") non di aggiustarsela... cosa peraltro ben
diversa...
Saluti,
Francesco

mc6491@_
su_mclink.it
 wrote:
 >Ma Unix ( e meglio ancora Linux) è realmente un oggetto
 >al quale possa essere applicato un metodo industriale
 >canonico?
Boh. Ma chi se ne frega? Ci sei proprio affezionato al "metodo
industriale canonico"? Io no.


 di Unix, forse... (pensadoci bene, pero`...).
Mah, di una shell decente si, pero`, se vuole rinominare tutti i file con una certa estensione in nomefile_numero_sequenziale.estensione...
:-)
(vedi un post in it.comp.linux... :-)
-- 
  Da visitare: la homepage del progetto GNOME (En)
http://www.gnome.org

industriale canonico"? Io no.
Io molto meno di te. E per questo sono contento che Linux esista.
Saluti.

 architetti, medici... e programmatori.
Caro, guarda che per buona parte delle cose che vengono richieste siamo al livello dei mobili in scatola di montaggio.
Prendi 1 cacciavite e te lo monti.
-- 
  Da visitare: Linux ed i computer portatili (En)
http://www.cs.utexas.edu/users/kharker/linux-laptop
http://www.aspide.it/mirrors/laptop
 	              (official mirror)
http://www.uu.ml.org/Linux/users/kharker/linux-laptop
 (official mirror)

 della parola (puoi leggere CAPITALISMO). E  questo č un bene.
Evidentemente, le compagnie di telecomunicazioni in tutto il mondo non fanno parte del capitalismo... :-)
Ti rendi conto che hai scritto una cosa molto opinabile?
-- 
  Da visitare: la homepage di Linus Torvalds (En)
http://www.cs.helsinki.fi/~torvalds

 direttamente nel contratto tra chi produce e chi acquista.
Mah, c'e` modo e modo di passare un test di integrazione e un component test.
Checche` se ne dica, se l'azienda lavora a compartimenti assolutamente stagni, i problemi rimangono (di altra natura, ma rimangono),
specialmente se i prodotti devono essere profondamente integrati tra loro.
IMHO, per gli OS non funziona. Benche` ciascuno degli omini di una nota azienda abbia in carico la manutenzione di meno di un terzo delle
linee di codice che ho in manutenzione io (calcolatrice alla mano, questo salta fuori).
-- 
  Da visitare: il sito del Pluto, con molta documentazione in italiano (It)
http://www.pluto.linux.it

 Prendi 1 cacciavite e te lo monti.
Certo, ma nei mobili in scatola di montaggio stile Ikea c'e' incluso
un bel foglietto con scritto "questo pezzo qua devi metterlo la', quel
pezzo la' devi metterlo qua" (scusate la pessima interpretazione di
Salvi),
ed e' fatto per un problema strumentale: occupano meno spazio. Se la
Microsoft ti vendesse Office in scatola di montaggio con un po' di
componenti e qualche riga di codice e un manuale per spiegarti come
compilarti il tutto, mi sembrerebbe abbastanza subito, fanno prima a
venderti Office gia' pronto, no?
E se poi te lo vuoi personalizzare, torniamo al discorso di prima:
c'e' chi e' capace e chi no. E chi non lo e' preferisce avere tutto il
pacchetto pronto. Chi lo e' si procura un compilatore e se lo fa.
-- 
Gabriele Biffi
gbi...@usa.net
 - ICQ: 5169491
http://www.rete039.it/civis/gbiffi/
"Il Pensiero genera l'Eresia; l'Eresia genera il Castigo." - WarHammer

 dovrebbe avere i font cirillici, credo.
Ma non ragiona con formati standard, ne ha uno proprietario.
In un sistema Unicode hai qualcosa come 65000 caratteri diversi, e
quindi riesci a farci stare i caratteri latini, greci, arabi,
cirillici, ebraici, cinesi, giapponesi, coreani, nonche' lettere
accentate di tutti i tipi possibili e simboli di ogni genere, e tutto
e' perfettamente catalogato. In ASCII abbiamo invece solo 96
caratteri...


Ti rendi conto che hai scritto una cosa molto opinabile?
Non vedo cosa c'entri con Unix e Linux comunque:
Le compagnie di telecomunicazioni sono oggi il CAPITALISMO. Che si è fatto
furbo.
Guarda la composizione dell'azionariato di Telecom (potevo prenderne una a
caso..)
70% ed oltre frazionato sul mercato (piccoli risparmiatori) e 10% allo
Stato, 20% ad investitori
istituzionali (ora le grandi concetrazioni si chiamano così). Frà questi la
Fiat con un 6% scarso controlla
il consiglio di amministrazione. Ossia, come com un 6% si acquista il
controllo totale di un'azienda.
Questo significa che il capitalismo, a differenza di quello che accadeva 50
anni fà, ottiene lo stesso risultato
spendendo 18/20 volte meno.
Saluti.

 
Veramente tu hai mosso una critica pesante (in pratica hai vietato l'uso
del computer a chi non e' capace di programmare) al mercato del softare
in se', se ti sei espresso male o ti sei fatto prendere la mano non e'
colpa mia.
Ciao,
       Antonio
P.S.:
      Puo' darsi che tu abbia letto il mio post senza ordinarlo nel
thread: in quel caso  p        posso ritenere piu' che comprensibile la
tua risposta.

 
Java ad esempio nacque per fornire la stessa interfaccia ai dispositivi
per la tv via cavo.
Ciao,
     Antonio

 Saluti.
Guarda che sei tu totalmente fuori strada.
Qui si parla di ingegneria del software.
Si tratta di controllare la produzione del software, di razionalizzarla
in maniera da aumenterne riusabilita' e manutenibilita'.
Mettendo in un'ottica da Grande Fratello sei totalmente OT.
Ciao,
     Antonio
P.S.:
     Mischiare tecnologia/scienza e politica e' cosa immonda.

Fiat con un 6% scarso controlla
0.6%
ciao
marco

 furbo.
Domanda iniziale: UNIX e` applicabile in un moderno concetto di sviluppo industriale del software?
Ovvero, non piu` software *house*, ma software *factory*?
La mia risposta e` un sonoro SI. Ne ho la dimostrazione tutti i santi giorni, dove lavoro. Se dove lavoro io non va bene, guardati Lucent
Tecnologies o qualunque altra azienda pluricertificata ISO e CMM >= 3 che sviluppi sofwtware per telecomunicazioni  (che DEVONO avere un
processo ben definito per lo sviluppo del sw se vogliono stare al passo con le esigenze che nasceranno nel giro di due o tre anni).
Accanto a questo, rimango tuttavia dell'opinione (personale) che un processo di produzione del software ben definito NON BASTA da solo a
soddisfare completamente le esigenze di un cliente, e che questo si deve sposare con l'esperienza di chi lo implementa (il processo). 10
progettisti geniali non tirano avanti nel lungo termine un'azienda di questo tipo, ma nemmeno N centinaia di  persone mediocri.
Linux in questo contesto inizia a farsi strada, piano piano, anche se le esigenze di assistenza in questo campo vanno ben oltre quanto e`
messo a disposizione oggi come oggi. Il resto del panorama e` HP-UX, Solaris e Digital UNIX, con NT come mero terminalino quando gli va bene
(workstation HP altrimenti), e conta di restare un terminalino ancora per diversi anni, quantomeno fintantoche` qualcuno diverso dalla
azienda che lo produce non dimostrera` che e` sensato portarci anche le parti server.
Spero vivamente che NT 2000 riesca a mantenere le promesse fatte, e che valga la pena portarci qualcosa di piu` di un pugno di GUI.
-- 
  Da visitare: news sulla sicurezza (En)
http://www.rootshell.org

 Salvi)
Mi pare che ogni anno si vendano anche tonnellate di libri e documentazione varia sul come programmare, sul come progettare software e sul
come produrre processi per la produzione industriale di software.
Insomma: utilizzare un computer nel lavoro di tutti i giorni con a fianco una lista sommaria del "cosa fare se..." e andare in panico
completo quando la situazione non e` presente nella lista e` come prepararsi ad un esame imparando a memoria un Bignami. 
Molto riduttivo (e mortificante). E, soprattutto, rende a rischio il futuro professionale di chi, per una certa ottusita` (scartando quindi
in partenza i problemi legati al tempo), fa a mano cio` che un computer puo` fare altrettanto bene e con altrettanta diligenza (dedicandosi,
in pratica, a cose stupide, visto che i computer sono macchine stupide e ottuse).
-- 
  Da visitare: Progetto per un accesso piu` intuitivo a Linux (En)
http://www.seul.org

 file di Word o in file HTML. Sempre testo e'.
Apprezzo unicode (sarebbe stato da fare prima). Tuttavia tieni presente anche che se domani da questo newsgroup ti dovessi scaricare
esattamente il doppio dei bytes, forse ti lamenteresti, o no? 
E che l'HTML in unicode sarebbe anch'esso lungo il doppio. Insomma, i vantaggi per l'internazionalizzazione ci sono, ma ci sono anche
evidenti svantaggi (o, se vuoi, evidenti vantaggi per le compagnie telefoniche, per i produttori di memorie di massa, etc. etc. etc.). In
molti casi i vantaggi superano gli svantaggi, in molti altri no.


Mischiare tecnologia/scienza e politica e' cosa immonda.
Si ma non confondiamo la tecnologia con la scienza.
La tecnologia non è la SCIENZA. La tecnologia (anzi le tecnologie)
sono in realtà la risultante di indirizzi di POLITICA ECONOMICA.
Le ciambelle con il buco possono essere prodotte che N tecnologie diverse.
Saluti.

Antonio Marullo (
anma...@iol.it
) wrote:
: Andrea Foco wrote:
[ snip ]
: Cioe' il fatto che un software sia ultraefficiente e' di importanza
: secondaria rispetto a come si arriva al prodotto finale, quanto il
: processo di produzione del SW sia documentato etc.
Scusa ma non mi e' chiaro...a meno che tu non stia parlando della
importanza della documentazione e della manutentibilita' del SW.
: > [ snip ]
: C'entra eccome.
: Definiresti un lavoro serio un programma ultraefficiente che fa quel che
: deve fare, ma senza capo ne' coda, totalmente immantenibile.
No, ma secondo te sarebbe serio un prodotto completamente documentato, che
pero' non fa quel che deve fare ?
: > [ snip ]
: > Ma...questa e' una storia che gira da un po' di tempo, pero' non mi
: > sembra che sia cosi' simile, ad esempio, all'elettronica di consumo:
: > potrebbe diventarlo se ci fosse un SO standardizzato che gira su un
: > HW standardizzato, e il mercato fosse principalmente sui prodotti
: > software.
: > 
: Beh no.
: Direi anzi che nell'elettronica di consumo e' quasi impossibile trovare
: prodotti totalmente standard.
Mah...io non sono un appassionato, ma amici che lo conoscono piu' di
me dicono che i produttori sono pochi, poi si rimarchia, ecc.
: Basti pensare ai videoregistratori e alla loro programmazione.
Che il 90% degli utilizzatori non sa usare ;)
: Od agli apparati stereo con le loro features opzionali.
Idem come sopra...
: Se ci sembrano alla nostra portata e' perche' sono dispositivi
: estremamente semplici se rapportati ai computer.
Affatto. Il punto e' che le 'funzioni di base' (registrare e riprodurre)
sono alla portata della maggior parte degli utilizzatori (gia' il timer
e' un'altra storia ;). E nota che i comandi per le funzioni di base sono
praticamente equivalenti da un modello all'altro.
Il resto delle 'features' serve solo per promuovere la vendita, in genere 
chi compra non e' che poi sia realmente in grado di utilizzarle...per cui 
il fatto che siano diverse non e' poi cosi' rilevante.  


 molti casi i vantaggi superano gli svantaggi, in molti altri no.
 Immagino coloro che disegnano i font. A dovere disegnare 65000 
caratteri.
 Quando avevo Amiga avevo un font editor vettoriale per Type1 e True 
Type. Si chiama TypeSmith e spesso trovavo tanti font in giro ma 
alcune vole non avevano le lettere accentate cosi' copiavo le vocali e 
giocando di shift e ridimensionamento dell'apostrofo riuscivo a 
mettergli gliaccentini e crearmi quei caratteri per il mio 
wordprocessing giornaliero.
 Come si fa con 65000 caratteri?
 Beh diciamo ci aggiungiamo solo quelli che ci servono cosi' fara' un 
greco, un turco, un tailandese ecc.
--
Ciao.
 Mr. Mechano

deve fare, ma senza capo ne' coda, totalmente immantenibile.
Secondo un paio di linee di filosofia, il primo caso si verifica solo
in assenza dei requisiti esposti a valle.
Obelix


Non direi, altrimenti la gente dovrebbe comprare solo in base al prezzo
del prodotto e non in base alle funzionalita' offerte (tanto non le
usa).
Ciao,
      Antonio

 
Hmmm, mi spieghi che c'entra la politica economica con il bus SCSI(tanto
per dire qualcosa)?
Ovviamente l'economia entra in gioco nelle scelte di minimizzazione dei
costi/massimizzazione delle prestazioni ma non mi sembra che stessimo
parlando di questo
Ciao,
      Antonio
P.S.:

 
Spesso certi programmatori sembrano sfidare ogni logica.
Ciao,
     Antonio

 in pratica, a cose stupide, visto che i computer sono macchine stupide e ottuse).
Credo di non aver capito bene quello che vuoi dire. Puoi riformulare,
please?


matteoi...@poboxes.com
 wrote:
 >E che l'HTML in unicode sarebbe anch'esso lungo il doppio. Insomma, i vantaggi per l'internazionalizzazione ci sono, ma ci sono anche
Non in questo caso. Usenet ha gia` un meccanismo di i18n perfettamente
funzionante, basta implementarlo.
Per favore scrivi righe non piu` lunghe di 72 caratteri.


 greco, un turco, un tailandese ecc.
Ovviamente col fai-da-te costruirsi 65536 caratteri e' un po' un
suicidio... ma se sei un professionista, e' il tuo compito. Te li fai.
E comunque scusa, mica e' obbligatorio farseli tutti (anche perche' al
giorno d'oggi di questi 65000 ne sono usati "solo" qualche migliaio,
difatti non hanno avuto nessun problema ad inserire il simbolo
dell'euro).


 molti casi i vantaggi superano gli svantaggi, in molti altri no.
Tanto oggi ci sono gią talmente tante cose inutili, cosa piu' cosa
meno... almeno questa servirebbe a qualcosa.


 Hai mai guardato da dentro qualche eseguibile di windows ?
Questo mostra due cose:
1) non sai cos'e' Unicode
2) pensi che in un eseguibile Linux invece ci sia scritto "vai a capo,
scrivi ciao mondo e termina". Mi spiace deluderti, ma con _qualsiasi_
eseguibile di _qualsiasi_ sistema ci sono dati binari, mica ASCII,
percio' di un editor di file di testo non te ne fai assolutamente
nulla.


 Proponilo ai tuoi corrispondenti russi e guarda cosa ti rispondono...
Mi hanno gia' risposto. Piace anche a loro. Non ne possono piu' di
dover inviare anche i font truetype oltre ai documenti.


 colpa mia.
Ho gia` risposto altrove a questa interpretzazione.
bye,
--
  Piergiorgio Sartor
  Sony International (Europe) GmbH
  European R&D Stuttgart
  Advanced TV Group              Tel.: 
++49-(0)711-5858-525
  Stuttgart Technology Center    FAX: 
++49-(0)711-5858-199
  Stuttgarter Strasse 106        e-mail: 
sar...@sony.de
  D-70736 Fellbach, Germany

per dire qualcosa)?
C'entra perchè il costo industriale di un controller Adpatec 2940U2W è di
13.500 lire.
Mentre quello di un disco Scsi U2W  è di 87.000. Solo che tu quel controller
lo paghi una cifra enormente più elevata (e il mark-up non è giustificato
dal profitto)
Lo paghi tanto perchè si vuole porre un freno all'uso diffuso di tecnologie
che possono
dare un vantaggio competitivo (che in ultima analisi stà sempre nel
miglioramento
del rapporto investimento/risultato).
Saluti.

 fare se parte la FAT.
Guarda che la mia ragazza ha la patente sa come cambiare una ruota e sa
dove si trovano i fusibili ma dubito che tenterebbe di farlo,
chiamerebbe un meccanico comunque sia.
Ciao
Francesco

 LINUS  diventa SUNIL (SUN IL)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Si avevo capito bene... ti sei fumato qualcosa se hai il tempo per stare
a pensare a 'ste cose. Mischiare economia ed informatica come fai tu mi
sembra alquanto discutibile.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>

 solo se manca, pero`, e` chiaro questo.
Dato che non e' corretta la premessa la conclusione deve essere rivista
altrimenti nascerebbe il WP FranzWord 1.0 :-)))))))
Non tutti sono in grado di scrivere SW e non tutto il SW commerciale
puo' essere facilmente riscritto sulle proprie esigenze.
Ciao
Francesco

 puo' essere facilmente riscritto sulle proprie esigenze.
Non parlo di "riscrittura", ma di "scrittura" e` PROFONDAMENTE
diverso, rifletti un attimo:
non devo rifare Word ex-novo, solo freeware, ma devo fare un SW
che mi sia utile, sempre che non si trovi quello commerciale.
Io mi ricordo che all'epoca del C64 ci si scriveva il SW in "casa",
poi, dato il successo del HW, e` piovuta una quantita` di SW
(piratato) immensa, tale da rendere impossibile la scrittura
in "casa", perche` il SW esisteva gia` fatto e pure meglio.
Oggi, credo, per molte cose siamo tornati indietro, pochi OS, pochi
applicativi, per lo piu` monomarca, molta gente che dice di "non trovare
il SW adatto" o "di usare SW schifoso", non sono parole mie, l'unica
soluzione, allora, e` scrivere da se il SW.
Concorderei sul fatto che oggi e` piu difficile, forse, ma
non accetto che la gente non prenda in considerazione la
possibilita` di autocostruirsi il SW.
Riguardo l'automobile:
ho scritto riparare, perche` costruire un'auto in casa crea
qualche problema legale, leggi omologazione. Inoltre gli oggetti
fisici hanno un costo in termini di materiali, il SW no, non ha
materie prime necessarie (non e` una mia idea questa).
Se trovassi un kit per auto con costo << del modello preconfezionato
lo comprerei subito, sempre che sia valido, of course.


sembra alquanto discutibile.
Pierluigi, frà qualche anno, quando sarai più anziano, vedrai le
cose con uno spirito diverso.
Saluti.

 Saluti.
Ammesso e non concesso che tu affermi il vero, non vedo dove stia questo
complotto.
Acquistando un prodotto Adaptec paghi oltre al prezzo il supporto, la
garanzia ed il "nome".
Inoltre nessuno vieta che se un costruttore di controller SCSI voglia
vendere prodotti di alta qualita' (nella fattispecie controller) a
20.000 lire non possa farlo.
Anzi, potendo lo farebbe sicuramente conquistandosi gran parte del
mercato.
Se non conoscessi la serieta' dei tuoi post direi che leggi troppi
romanzi.
Ciao,
      Antonio

 cose con uno spirito diverso.
Non vorrei spezzarti il cuore, ma sai almeno quanti anni ho? Sai, questa
abitudine che c'e' di giudicare con leggerezza l'eta da cio' che si scrive
puo' portare a cantonate eclatanti...


 lo comprerei subito, sempre che sia valido, of course.
Certamente la mia ragazza che regola gli iniettori o monta
un'alternatore potrebbe essere uno spettacolo divertente .
Non siamo tutti uguali.
Ciao
Francesco

 Non siamo tutti uguali.
Per fortuna!
Ma questo NON vuol dire che siamo tutti incapaci...


gbi...@usa.net
 wrote:
 
 >>  >Perche' i file di testo devono per forza essere ASCII, limitato a 128
 >>  >caratteri (anzi, 96, visto che i primi 32 sono di controllo)? Al
 >> Perche` ci sono newsreader schifosi tipo free agent che non gestiscono
 >> MIME.
 >Non c'entra un fico secco.
Si che c'entra. Perche` se tutti usassero MIME tutti potrebbero usare la
codifica a 8 bit che preferisono e nessuno avrebbe problemi.
Invece ho dovuto smettere di usare Latin-9 per colpa dei merdosi
newsreader per windows e dei loro utenti.
Mi sembra che tu sia molto poco preparato sulle problematiche di i18n.
 >>  >Non so voi, ma io tifo per Unicode e abbasso ASCII.
 >> Proponilo ai tuoi corrispondenti russi e guarda cosa ti rispondono...
 >Mi hanno gia' risposto. Piace anche a loro. Non ne possono piu' di
Evidentemente sono utenti lobotomizzati. Tutti i russi con un minimo di
conoscenza del problema sanno bene che i loro dati diventerebbero
magicamente grossi il doppio passando da KOI-8 a unicode e quindi se ne
guardano bene.
 >dover inviare anche i font truetype oltre ai documenti.
Ho capito. Tu credi che un OS che usa unicode sia magicamente fornito
dei glyph per l'intera codifica. E` assolutamente falso.
Anche se usassi unicode dovresti comunque procurarti i font cirillici,
come quelli per jp-kr-cn, indiani, etiopici, eccetera.


gbi...@usa.net
 wrote:
 >2) pensi che in un eseguibile Linux invece ci sia scritto "vai a capo,
 >scrivi ciao mondo e termina". Mi spiace deluderti, ma con _qualsiasi_
 >eseguibile di _qualsiasi_ sistema ci sono dati binari, mica ASCII,
 >percio' di un editor di file di testo non te ne fai assolutamente
 >nulla.
Curioso. .LC0 mi sembra proprio una stringa ASCII:
md@wonderland:1:~$cat >hello.c
int main()
{
    printf("\nHello, world.\n");
    exit(0);
}
^D
md@wonderland:1:~$gcc -O1 -S hello.c
md@wonderland:1:~$cat hello.s
        .file   "hello.c"
        .version        "01.01"
gcc2_compiled.:
.section        .rodata
.LC0:
        .string "\nHello, world.\n"
.text
        .align 16
.globl main
        .type    main,@function
main:
        pushl %ebp
        movl %esp,%ebp
        pushl $.LC0
        call printf	! va a capo, scrive ciao mondo
        pushl $0
        call exit	! e termina
        .align 16
.Lfe1:
        .size    main,.Lfe1-main
        .ident  "GCC: (GNU) 2.7.2.3"
md@wonderland:1:~$rm -f hello.*
md@wonderland:1:~$
Se proprio vuoi posso anche allegare un hexdump per farti vedere che
printf stampa caratteri ASCII.



Ecco, anche questo; molta gente sa (almeno in teoria) fare moltissime
cose, ma in pratica non le fa perche' non si fida. Riguardo al
software sento spesso questa obiezione: "ma se gia' l'uomo piu' ricco
del mondo non riesce a fare qualcosa che funziona, perche' dovrei
riuscirci io?".
Ma certo neanch'io sopporto quelli che mi telefonano (immancabilmente
quando sono in bagno, manco lo sapessero) per chiedermi cose del tipo
"ma come faccio a far partire quel gioco, clicco su Avvio e non c'e'".


         .ident  "GCC: (GNU) 2.7.2.3"
A me questo non sembra proprio un file compilato, ma assembly DA
compilare (mentre tu li hai semplicemente cancellati; se avviavi
questo, Linux ti avrebbe mandato a quel paese).
Eccoti i primi non so quanti byte di un eseguibile linux compilato.
01111111 01000101 01001100 01000110 00000001 00000001 00000001
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000010 00000000 00000011 00000000 00000001 00000000 00000000
00000000
00000000 00001110 00000000 00001000 00110100 00000000 00000000
00000000
10011100 10101100 00000000 00000000 00000000 00000000 00000000
00000000
00110100 00000000 00100000 00000000 00000101 00000000 00101000
00000000
00010100 00000000 00010011 00000000 00000110 00000000 00000000
00000000
00110100 00000000 00000000 00000000 00110100 00000000 00000000
00001000
00000000 00000000 00000000 00000000 10100000 00000000 00000000
00000000
10100000 00000000 00000000 00000000 00000101 00000000 00000000
00000000
00000100 00000000 00000000 00000000 00000011 00000000 00000000
00000000
11010100 00000000 00000000 00000000 11010100 00000000 00000000
00001000
00000000 00000000 00000000 00000000 00010011 00000000 00000000
00000000
00010011 00000000 00000000 00000000 00000100 00000000 00000000
00000000
00000001 00000000 00000000 00000000 00000001 00000000 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00001000
00000000 00000000 00000000 00000000 00100101 10011111 00000000
00000000
00100101 10011111 00000000 00000000 00000101 00000000 00000000
00000000
00000000 00010000 00000000 00000000 00000001 00000000 00000000
00000000
00101000 10011111 00000000 00000000 00101000 10101111 00000000
00001000
00000000 00000000 00000000 00000000 10011000 00001011 00000000
00000000
11001100 00010010 00000101 00000000 00000110 00000000 00000000
00000000
00000000 00010000 00000000 00000000 00000010 00000000 00000000
00000000
00110000 10101010 00000000 00000000 00110000 10111010 00000000
00001000
I tre byte dopo il primo sono la stringa ELF - il formato che
identifica gli eseguibili linux. I caratteri ASCII sono quelli
compresi tra 00100000 (32, lo spazio) e 01111111 (127, non so cos'e'
ma e' comunque ASCII). Come puoi ben vedere, qui ci sono molti
caratteri (la maggioranza, diciamolo) che non sono affatto ASCII.
Inoltre, il ritorno a capo e' il carattere 10 (00001010), quanti ne
vedi?
Inoltre, se Linux compilasse i suoi file all'avvio, avremmo delle
performance talmente penose da farci rimpiangere il DOS.
Dai, ammettilo che hai sparato una cavolata.


 Dai, ammettilo che hai sparato una cavolata.
Qua mi sa che la cavolata l'hai sparata tu...
Saluti,
Fabio Alemagna

Spesso certi programmatori sembrano sfidare ogni logica.
Ok, ma il programma tente a non funzionare..
Obelix

risposta: Mio Dio NO!
Risposta errata: noi lo stiamo riscrivendo.. oddio, ci vorrano 10
anni, ma...  :-))
Obelix

 dei glyph per l'intera codifica.
Mi spiace deluderti, ma non hai capito affatto. Sto dicendo che se un
sistema fosse abbastanza serio, le avrebbe, almeno in un font.


mercato.
Quando i produttori di componenti controller SCSI al mondo sono 3 non c'è
niente da concorrere.
Saluti.

puo' portare a cantonate eclatanti...
Da 23 a 26 anni.
Non di più a giudicare dalla foto della prima cena pubblicate da Max Adamo.
Saluti.

 da parte di TIM e Omnitel.
Subito censurato dall'Authority.
Ok spero di non aver buttato troppa benzina sul nostro flame, ma in fin
dei conti i news sono fatti per discutere, no?
Ciao,
       Antonio

 Non di più a giudicare dalla foto della prima cena pubblicate da Max Adamo.
Ecco, hai preso una cantonata... sono del '64. E poi le foto sono state
pubblicate da Leonardo, per dovere di precisione.


 Ammetto di non sapere cosa sia.
internationalization ... pant, pant, riprendo fiato.
Semplificato in i<altri 18 caratteri in mezzo>n
-- 
Davide   |`. /\    
albe...@usa.togli.questo.net
   | PGP KeyID:
Alberani |__)~~\ 
http://members.xoom.com/alberanid/
 | 0xD0354739

dei conti i news sono fatti per discutere, no?
Si.

pubblicate da Leonardo, per dovere di precisione.
Canton stà in Cina. C'è un nesso a SUN e Oracle anche nelle parole Canton e
Cantonata.
Però non te lo spiego.
Saluti.

 Però non te lo spiego.
Sto gia' soffrendo a.k.a NMPFDM ;-)


Scusami Gabriele,
    ma noto, che hai questa specie di tendenza all'esalatzione delle
competenze col metro del'eta anagrafica, e non solo.Quasi tutti i tuoi
discorsi celano un pensiero, a volte non lo celano come in questo caso, che
sembra dire: "..ma guarda questi ragazzini, basta che si mettono un sistema
operativo davanti, leggono quattro info e si sentono padroni del mondo....non
sanno quale è il vero lacvor del sistemista.....".
Ora, a parte le età di coloro che ti rispondo, che penso siano molto
variabili, compreso me che ne ho quasi 27, ti chiedo come mai continui a
distribuire saggezza a noi bambini di ICOD??? ...azzardo una ipotesi....
Il tuo comportamento è tipico degli anziani manager di qualche fabbrichetta
del nord che continuano a lavorare pensando che il loro lavoro, come la loro
persona, è insostitubile: dopo di me il buio, l'apocalisse....non penso sia
così, e ogni volta che si tira fuori un discorso serio tu sei lì pronto
dall'alto della tua veneranda età (che tra l'altro continui a non dichiarare)
a dispensare buoni propositi e future possibilità di conoscenza, sempre per i
poveri bambini di ICOD, dei segreti che continui a custodire gelosamente,
tranne quelli di winNT, che sono ben accetti dai bambini di quel gruppo.
Il bello dei gruppi e che ognuno ha la sua da dire, a prescindere dall'età;
se quello che dico è una palese cavolata, mi ritroverò con decine di persone
di qualsiasi età a dirmi che ho detto una cavolata, qui su ICOD oltre quelle
decine di persone c'è ne una che mi dirà: "..hai detto una cavolata, ma fra
qualche anno non la dirai più...."....che bello, abbiamo il papà di ICOD.....
                        Michele Nicosia, 16/7/73

Antonio Marullo (
anma...@iol.it
) wrote:
: Andrea Foco wrote:
: > 
: > Antonio Marullo (
anma...@iol.it
) wrote:
: > : Andrea Foco wrote:
[ snip ]
: > No, ma secondo te sarebbe serio un prodotto completamente documentato, che
: > pero' non fa quel che deve fare ?
: > 
: Il prodotto non lo finisci se non rispetta la specifica, se te ne
: intendi un minimo di ingegneria del software sai quello che intendo.
Ti faccio notare che se anche se un prodotto SW risponde perfettamente 
alle specifiche, non e' detto che funzioni correttamente. Un esempio 
famoso e' il disastro di Ariane 5.
: > 
: > Il resto delle 'features' serve solo per promuovere la vendita, in genere
: > chi compra non e' che poi sia realmente in grado di utilizzarle...per cui
: > il fatto che siano diverse non e' poi cosi' rilevante.
: >
: Non direi, altrimenti la gente dovrebbe comprare solo in base al prezzo
: del prodotto e non in base alle funzionalita' offerte (tanto non le
: usa).
Sarebbe vero se:
1) la 'gente' fosse razionale.
2) la 'gente' fosse perfettamente informata.
3) la 'gente' comprasse una data cosa perche' le serve, e non per 
   soddisfare altri impulsi.
In tal caso, gli esperti di marketing dovrebbero trovarsi un altro
lavoro ;)
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

gbi...@usa.net
 wrote:
 >>  >dover inviare anche i font truetype oltre ai documenti.
 >> Ho capito. Tu credi che un OS che usa unicode sia magicamente fornito
 >> dei glyph per l'intera codifica.
 >Mi spiace deluderti, ma non hai capito affatto. Sto dicendo che se un
 >sistema fosse abbastanza serio, le avrebbe, almeno in un font.
Puo` averle indipendentemente dal fatto che usi unicode o un encoding a
8 bit classico.


gbi...@usa.net
 wrote:
 >A me questo non sembra proprio un file compilato, ma assembly DA
 >compilare (mentre tu li hai semplicemente cancellati; se avviavi
Non e` certo di questo che stiamo discutendo. Comunque...
md@wonderland:2:~#gcc -O1 hello.c
md@wonderland:2:~#hexdump -c < a.out
[...]
0000500 350   K 377 377 377 213   ] 374 211 354   ] 303  \n   H   e   l
0000510   l   o   ,       w   o   r   l   d   .  \n  \0  \0  \0  \0  \0
[...]
Ecco li` la nostra stringa ASCII, e non unicode.
 >ma e' comunque ASCII). Come puoi ben vedere, qui ci sono molti
 >caratteri (la maggioranza, diciamolo) che non sono affatto ASCII.
Mi pare abbastanza ovvio, gli opcode x86 coprono quasi tutti i
byte disponibili.


Antonio Marullo (
anma...@iol.it
) wrote:
: Andrea Foco wrote:
[ snip ]
: > Ti faccio notare che se anche se un prodotto SW risponde perfettamente
: > alle specifiche, non e' detto che funzioni correttamente. Un esempio
: > famoso e' il disastro di Ariane 5.
: > 
: Guarda che il caso dell'Ariane 5 non e' citabile.
: In particolare esso e' stato causato proprio da una cattiva
: documentazione del sistema.
Be'...io ho sentito un'altra campana ;)
: Nella conversione dei programmi del controllo da Ariane 4 ad Ariane 5
: non ci si accorse o ci si scordo' che in alcuni pezzi di software
: scritti in assembler si faceva affidamento sulla lunghezza della word
: del microcontrollore per alcune ottimizzazioni.
: Nel porting si passo' ad una architettura HW con lunghezza di parola
: diversa, ma ci si scordo' di riscrivere il codice tenendo conto della
: nuova lunghezza della parola.
: Cosi' ecco il botto!
: La colpa? 
: 1) Di chi scelse di scrivere quei pezzi di codice in assembler cercando
: ottimizzazioni della domenica
ROTFL !
: 2) Di chi non seppe o non volle documentare quelle ottimizzazioni.
Ho letto un articolo su CP in cui si analizzava la ricostruzione della
commissione d'inchiesta: il punto e' che nel modulo SW incriminato vi
erano 7 operazioni di conversione, ma per i vincoli sull'utilizzo della
CPU, solo 4 di esse furono protette.
Il tutto fu ratificato da una nutrita schiera di controllori, che pero'
non misero in evidenza questo fatto.
Con l'Ariane 4 ando' tutto bene, cosi' quando si passo' al 5 (complice
la soppressione per motivi di bilancio della simulazione completa del
volo con la nuova traiettoria) nessuno si accorse del problema.
Potresti chiamarla cattiva documentazione, se non fosse che:
"L'inchiesta ha appurato che vennero seguite tutte le procedure sulla
 documentazione, validazione e gestione del progetto, procedure che 
 all'ESA sono allo stato dell'arte".  (CP 69, pag. 98)
: Nei corsi di S.O. che coprono i sistemi real time il caso dell'ariane 5
: viene citato proprio per mettere in guardia contro la tentazione di
: scrivere codice ultraottimizzato in assembler per guadagnare qualche
: millesimo (con un BUON compilatore C ottieni gli stessi risultati senza
: rischiare).
Peccato che il caso dell'Ariane 5 non c'entri nulla con la (non
necessaria) ultraottimizzazione del codice: come gia' scritto, 
la decisione di non proteggere quell'operazione di conversione 
era perfettamente legittima, e rispettava le specifiche.


 rischiare).
Purtroppo non e` sempre cosi`:
1) i compilatori fanno codice "lento"
2) i compilatori fanno codice "grosso"
Tendenzialmente alcune applicazioni hanno SOLO
assembly; oggigiorno, per vari motivi, si preferisce
usare C, al prezzo di aver bisogno di CPU piu` potenti.
E piu` memoria...


 
Guarda che il caso dell'Ariane 5 non e' citabile.
In particolare esso e' stato causato proprio da una cattiva
documentazione del sistema.
Nella conversione dei programmi del controllo da Ariane 4 ad Ariane 5
non ci si accorse o ci si scordo' che in alcuni pezzi di software
scritti in assembler si faceva affidamento sulla lunghezza della word
del microcontrollore per alcune ottimizzazioni.
Nel porting si passo' ad una architettura HW con lunghezza di parola
diversa, ma ci si scordo' di riscrivere il codice tenendo conto della
nuova lunghezza della parola.
Cosi' ecco il botto!
La colpa? 
1) Di chi scelse di scrivere quei pezzi di codice in assembler cercando
ottimizzazioni della domenica
2) Di chi non seppe o non volle documentare quelle ottimizzazioni.
Nei corsi di S.O. che coprono i sistemi real time il caso dell'ariane 5
viene citato proprio per mettere in guardia contro la tentazione di
scrivere codice ultraottimizzato in assembler per guadagnare qualche
millesimo (con un BUON compilatore C ottieni gli stessi risultati senza
rischiare).
Ciao,
      Antonio


Purtroppo per l'Ariane c'entra eccome: niente ottimizzazione Assembly =>
nessun errore di porting => nessun overflow => nessun disastro! 
Ciao,
      Antonio

e per finire, continui a non dire quanti anni hai....
Due???
Obelix

Antonio Marullo (
anma...@iol.it
) wrote:
: Andrea Foco wrote:
: > 
: Guarda che a sbagliarti sei tu: o ricordi male cosa ha scritto CP, o CP
: non ha riportato tutta la storia.
: Citando l' ieee Transactions on Software Engineering vol.24 n.1:
[ snip ]
O.K. e in che modo cio' confuta quello che dico io, o sostiene quello
che dici tu ?
Quando ho scritto 'protette', intendevo contro l'overflow.
: In particolare l'errore di overflow che genero' l'eccezione fatale era
: dovuto appunto alla routine assembler in questione. 
Ma cio' che rese l'overflow catastrofico fu il fatto che non era gestito.
Il modulo in questione invio' un messaggio di errore, che venne interpretato 
dai moduli 'a valle' come un insieme di dati di volo provocando l'eccezione 
fatale (sempre secondo CP).
[ snip ]
: > Peccato che il caso dell'Ariane 5 non c'entri nulla con la (non
: > necessaria) ultraottimizzazione del codice: come gia' scritto,
: > la decisione di non proteggere quell'operazione di conversione
: > era perfettamente legittima, e rispettava le specifiche.
: >
: Purtroppo per l'Ariane c'entra eccome: niente ottimizzazione Assembly =>
: nessun errore di porting => nessun overflow => nessun disastro! 
Questo e' un pochino semplicistico, non pensi ?
Se hanno usato assembly ottimizzato era perche' serviva.
In quanto al fatto di utilizzare il C, ho l'impressione che dovessero
contare i cicli di clock utilizzati, e in assembly e' piu' facile ;)



No guarda che e' proprio lo stesso, basta sapere come compila e
scegliere il livello di pttimizzazione corretto.
Inoltre i calcoli li fai sul compilato e non sul sorgente.
Il controllo che hai sul codice prodotto e sulla sua velocita' di
esecuzione e' comunque totale, non usi cache ne' altra roba che potrebbe
falsare i tempi. 
Il punto e' e rimane che se si fosse usato C anziche' assembler e/o se
si fosse ben documentato il tutto mettendo il designer in condizione di
lavorare con sicurezza non si sarebbe arrivati al disastro.
Ciao,
      Antonio

 2) i compilatori fanno codice "grosso"
Meglio! Piu` si srotola il codice meglio funziona... Si evitano
problemi di salto, di dipendenze logiche tra istruzioni ecc...
 
-- 
# Giorgio Vecchiocattivi.
# Dip. Informatica, Universita` di Pisa. 
---
E` in corso la CFV per la moderazione di it.scienza.informatica.
Se siete interessati leggete l'articolo su it.news.annunci

 problemi di salto, di dipendenze logiche tra istruzioni ecc...
Sbagliato! I cache miss dove li metti? Inoltre un tipico
microcontrollore o DSP per controllo real time quanta
memoria credi che abbia? Forse 1 o 2 KB.
Poi ci sono i problemi di consumo, etc.
Non e` banale, soprattutto per applicazioni al limite,
come l'astronautica.
Il punto e` l'applicazione: se devi controllare qualcosa con
la risoluzione del uSec e non puoi avere un Pentium 500 MHz
cosa fai? Usi un DSP e lo programmi in assembly, ottimizzando
piu` che puoi.
Se poi vi sono problemi di comunicazione fra designer,
beh questa e` un'altra storia...
Il time-to-market e` il vero punto, quando si ha fretta
si va di codice C e magari si compra una CPU un po' piu`
veloce, tanto poi paga chi compra il prodotto (se sei il
primo a proporlo).


 Guarda che ti stai sbagliando e di molto.
Per i porcessori moderni pensare di programmare direttamente in
assembleer e' folle.
Inoltre il Pentium ha bisogno eccome di un compilatore ottimizzante a
meno che tu non voglia usarlo come un 486 overclockato.
Per DSP e microcontrollori vale lo stesso principio.
Quanto ai requisiti di memoria ti assicuro che si raggiungono e talvolta
si superano abbondantemente le centinaia di kb.
Ciao,
       Antonio

 si superano abbondantemente le centinaia di kb.
Il piu` diffuso microcontrollore e` l'Arizona Microchip,
versione 16Cxy e 12C50x (questo e` quello delle Playstation).
Hanno pochissima memoria, credo 256 byte RAM e 512 byte EEPROM,
forse anche meno, nelle versioni economiche.
Il 68HC11A1 della Motorola ha 512 byte eeprom e 245 byte RAM, pure lui.
Il TMS320C25 ha 544 word (1088 byte) di RAM interna, la versione E
ha anche 8K word di EPROM, ma costa una cifra.
Il TMS320C1x ha ancora meno memoria.
Il TMS320C32 (DSP FP) ha 64 (cache) + 512 + 512 long word (32 bit)
di memoria interna, ma tutto il codice e` 32 bit, quindi non
si puo` ragionare a byte.
Per i linguaggi:
Microchip si programma in assembly, forse c'e` il compilatore C,
ma non e` usato.
68HC11 ha un compilatore C, a volte usato (per via del FP, emulato),
di solito si usa assembly.
TMS320C25 e C1x hanno SOLO assembly.
TMS320C3x ha anche il compilatore C, ma anche questo e` poco
usato per via che fa andare il DSP al 50% delle sue potenzialita`.
Il TMS320C80 ha SOLO assembly.
Il TMS320C6xxx ha SOLO C, e` un VLIW.
Stesso discroso per i uC 68HC05 e 68HC08, solo assembly, poca memoria.
E per i uC a 4 bit, ancora usati (vedi computer da bicicletta) e` lo
stesso (credi ci sia un compilatore C per un affare a 4 bit?)
E il 6502, ancora disponibile ed usato?
Vuoi che continui?
Come scritto prima, dipende dall'applicazione e dai requisiti
di time-to-market.
In generale non e` affatto detto che il C sia utile od utilizzabile.


 Guarda che non devono mica avere la ram interna al chip per forza.
Io uso gli SHARC della Analog Devices (architettura super Harvard) che
hanno come compilatore C il mitico g21k.
Anziche' usare Ram interne si usano RAM sul bus e sinceramente per ogni
esempio che hai tirato posso tirartene uno opposto.
Senza contare che volendo per i var dsp della T.I. che hai citato e'
disponibile il compilatore C.
La tecnologia va avanti e le macchine migliorano cosi' come gli
strumenti per svilupparci sopra.
Quanto al pentium il compilatore e' necessario proprio per la gestione
della pipeline sopratutto considerando la sua natura "bastarda"
(possiamo vederlo come un incrocio RISC-CISC).
Ciao,
       Antonio

 primo a proporlo).
Pure questo e` vero. In generale pero` io sostengo, che un compilatore
crea codice assembler meglio di un essere umano.
-- 
# Giorgio Vecchiocattivi.
# Dip. Informatica, Universita` di Pisa. 
---
E` in corso la CFV per la moderazione di it.scienza.informatica.
Se siete interessati leggete l'articolo su it.news.annunci

        Antonio
Qui forse ti posso dare ragione....i micro, per cosi' dire "da computer"
sono in effetti un po' troppo complessi per poter essere sfruttati da
chiunque meglio che rispetto ad un compilatore.
Ciao Carlo

Antonio Marullo (
anma...@iol.it
) wrote:
: Andrea Foco wrote:
: > 
: > Antonio Marullo (
anma...@iol.it
) wrote:
: > : Andrea Foco wrote:
[ snip ]
: > Ma cio' che rese l'overflow catastrofico fu il fatto che non era gestito.
: > Il modulo in questione invio' un messaggio di errore, che venne 
: > interpretato dai moduli 'a valle' come un insieme di dati di volo 
: > provocando l'eccezione fatale (sempre secondo CP).
: > 
: Tu gestiresti una cout? il livello di affidabilita' che si dava a quella
: routine era proprio quello.
8-? Temo di non aver capito cosa intendi...
: > In quanto al fatto di utilizzare il C, ho l'impressione che dovessero
: > contare i cicli di clock utilizzati, e in assembly e' piu' facile ;)
: >
: No guarda che e' proprio lo stesso, basta sapere come compila e
: scegliere il livello di pttimizzazione corretto.
Ma per favore...
: Inoltre i calcoli li fai sul compilato e non sul sorgente.
Ma che stai dicendo ? Io intendevo che i conti si fanno sul listato
assembly, istruzione per istruzione, con un livello di granularita'
che non puoi avere con un listato C. E' piu' chiaro, adesso ?
: Il controllo che hai sul codice prodotto e sulla sua velocita' di
: esecuzione e' comunque totale,
Abbiamo dei punto di vista diversi, ovviamente, o un diverso concetto
di controllo totale...
: Il punto e' e rimane che se si fosse usato C anziche' assembler e/o se
: si fosse ben documentato il tutto mettendo il designer in condizione di
: lavorare con sicurezza non si sarebbe arrivati al disastro.
A mio avviso: non e' stato usato il C perche' serviva l'assembler e
non e' chiaro cosa intendi per 'ben documentato', visto che ti ho
gia' scritto che, secondo la commissione di inchiesta, le procedure
relative alla documentazione erano state seguite alla lettera.
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

sar...@sony.de.remove.this wrote:
 >Il compilatore e` ottimizzante per certe feature della FPU
 >e poche altre cose, si discuteva di questo in un altro
 >thread.
No, le istruzioni devono essere divise in due flussi per sfruttare le
due pipeline.
(Se sai farlo a mente in tempi ragionevoli non posso che farti i miei
complimenti...)
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | > Mettete 
maxa...@tin.it
 nel vostro killfile (Pub. progresso) <

Per quanto riguarda il C ti assicuro che e' possibile avere dati sui
tempi di una routine con precisione pari a quella dell'assembly.
Ovviamente non usando processori con cache, sapendo che tipo di codice
genera il compilatore etc etc.
Per quanto riguarda la documentazione sostengo che se chi ha scritto la
sua brava routine assembler avesse documentato che faceva affidamento
sulla dimensione della word del processore usato (visto che nel porting
sul nuovo HW non se ne e' tenuto conto) non si sarebbe verificato il
disastro.
Faccio peraltro notare che lo standard HOOD (quello che per contratto
l'ESA richiede per ogni progetto) non richiede obbligatoriamente che
tutte le scelte di codifica vengano riportate, una scelta del genere e'
lasciata alla sensibilita' di chi scrive il SW.
Quanto al discorso sulla cout la rigiro: tu metteresti una protezione
sulla printf? e' una routine semplice, di base, ultra affidabile, alla
quale non ti aspetteresti un overflow error...beh la routine di cui
stiamo parlando si riteneva che avesse quel livello di affidabilita'.
Peraltro, come la printf, non svolgeva compiti vitali per il controllo.
Poteva solo fare danno in modi imprevedibili come di fatto e' avvenuto.
Spero con quest'ultimo post di aver chiuso il nostro sottothread sul
caso Ariane 5.
Ciao,
        Antonio

se si fosse usato C anziche' assembler
Perche', da adesso il C non da' piu' overflow??
Obelix


No, ma di sicuro quando ricompili in genere non devi preoccuparti della
lunghezza dei dati che ci stanno sotto ed il programma risulta
certamente piu' comprensibile.
Chi ha effettuato il porting si sarebbe subito accorto
dell'ottimizzazione barbara usata senza alcun problema.
E' una questione di leggibilita', chiarezza e portabilita'.
Insomma tutto quello per cui e' nato il linguaggio C.
Ciao,
      Antonio

Antonio Marullo (
anma...@iol.it
) wrote:
: Per quanto riguarda il C ti assicuro che e' possibile avere dati sui
: tempi di una routine con precisione pari a quella dell'assembly.
Mi pare che non ci capiamo: certo che puoi avere i tempi di una 
routine in C, ma non hai la stessa possibilita' di intervento sul
codice. Se programmi in Assembly hai una grado di raffinatezza
decisamente piu' elevato.
[ snip ]
: Quanto al discorso sulla cout la rigiro: tu metteresti una protezione
: sulla printf? e' una routine semplice, di base, ultra affidabile, alla
: quale non ti aspetteresti un overflow error...beh la routine di cui
: stiamo parlando si riteneva che avesse quel livello di affidabilita'.
Cosa c'entra ? Di solito io non prendo i risultati di una printf
per elaborarli.
Inoltre forse c'e' un fraintendimento: non spettava ai moduli a valle
riconoscere l'errore.
Da come la ho capita io, il controllo sull'overflow non e' stato
fatto per 'mancanza di tempo'.
La cosa era stata progettata ed adattata per l'Ariane 4, e su
quest'ultimo fuzionava perfettamente.
Quando si e' passati all'Ariane 5, il potenziale problema non e'
stato notato (dico potenziale perche' secondo CP il modulo in 
questione avrebbe potuto essere disabilitato subito dopo il lancio).
Tu sostieni due cose:
1) ottimizzazione della domenica -- Permettimi di osservare che
   il codice e' stato rivisto e approvato da piu' persone, e che se
   e' stata utilizzata una routine assembler ottimizzata e' perche'
   serviva.
2) cattiva documentazione -- come ho gia' scritto, il livello di
   documentazione all'ESA e' piuttosto elevato. In un grosso progetto,
   /non/ si riesce a documentare/verificare/testare tutto. Certo chi
   ha scritto la routine avrebbe potuto metterlo piu' in evidenza,
   d'altra parte ricordati che la routine era stata scritta per
   l'Ariane 4, ed era perfettamente adeguata per quest'ultimo.
[ snip ]
: Peraltro, come la printf, non svolgeva compiti vitali per il controllo.
: Poteva solo fare danno in modi imprevedibili come di fatto e' avvenuto.
Appunto, questa e' la chiave, imprevedibili.
: Spero con quest'ultimo post di aver chiuso il nostro sottothread sul
: caso Ariane 5.
What's the matter ? Comunque basta che smetti di rispondere e, se non
interviene qualcun altro, il thread muore da solo ;)


dell'ottimizzazione barbara usata senza alcun problema.
E, probabilmente, se ne sarebbe persi almeno altrettanti, di errori...
Obelix

 crea codice assembler meglio di un essere umano.
Non sempre è vero... Ci sono molte cose che se fatte direttamente in
assembler sono molto più veloci, per il semplice fatto che il
compilatore non sa cosa vuoi ottenere dal tuo programma, tu sì.
Ciao,
Fabio Alemagna

 compilatore non sa cosa vuoi ottenere dal tuo programma, tu sě.
Come e' gia stato detto, dipende da quanto e' complessa l'architettura
della cpu, e da quanto tempo hai da perdere ad ottimizzare il codice.
Per la mia limitata esperienza, si puo fare un ottimo lavoro anche in C,
magari con un'efficienza globale facciamo del 90% di un buon assembler
costruito alla perfezione ma nel 10% del tempo. Per me basta.
Saluti
Lele

 della pipeline sopratutto considerando la sua natura "bastarda"
Si, ma e` per la FPU, non per il core x86.
bye,
--
  Piergiorgio Sartor
  Sony International (Europe) GmbH
  European R&D Stuttgart
  Advanced TV Group              Tel.: 
++49-(0)711-5858-525
  Stuttgart Technology Center    FAX: 
++49-(0)711-5858-199
  Stuttgarter Strasse 106        e-mail: 
sar...@sony.de
  D-70736 Fellbach, Germany

 crea codice assembler meglio di un essere umano.
Non sono d'accordo, in generale.
Se si usa un processore VLIW e` MOLTO difficile programmare in assembly,
per via del parallelismo.
Il compilatore C, pero`, non raggiunge il 100% delle prestazioni
teoriche, basta vedere l'assembly generato, si arriva a circa il 60%
"medio" (cioe` a volte il compilatore arriva al 80-90%).
Riscrivendo il programma C, avendo come feedback l'assembly, si arriva
anche all'80% medio, su piccole routine.
C'e` gente che prova ad usare l'assembly su VLIW...
Un processore come il C3x, che ha un compilatore C, si programma
in assembly, almeno per le parti critiche, perche` il compilatore C
non riesce a raggiungere buoni livelli di ottimizzazione, in quanto
non e` possibile riordinare le istruzioni in tutti i modi possibili
e trovare l'ottimo, mentre un cervello umano ci riesce.
A proposito di compilatori C:
float x, y;
x = y / 2.0;
lo squallido compilatore C di un DSP FP, mi compila sta cosa con
qualcosa come:
fdiv x, y, 2.0
che ci mette una ventina di cicli.
Per avere l'ottimo devo scrivere:
float x, y,
x = y * 0.5;
che diventa:
fmul x, y, 0.5
che ci mette 3 cicli..
Questo perche` il compilatore e` ottimizzante...
Questo succede su almeno 3 compilatori DIVERSI, cioe` di
diverse ditte, per 3 DIVERSE CPU...


 costruito alla perfezione ma nel 10% del tempo. Per me basta.
Infatti, dipende dall'applicazione, da quanto si vuole spendere, etc.
Un C25 esegue un tap di un FIR a 10MHz, se devo filtrare
un segnale audio (ammesso che si possa fare con una CPU a 16bit),
ho una freq. dati in input a 88.1 KHz, il che vuol dire che non
si puo` avere un FIR con piu` di 100 tap, circa, in assembly.
Quindi il filtro possibile sara` conseguenza di queste limitazioni.
Scrivendo lo stesso programma in C si perde il controllo ed il 90%
potrebbe non essere sufficiente.
BTW 90% e` una visione ottimistica, facile il 60-70%.


Mai provato a sviluppare direttamente in C e poi limare ed aggiustare le
cose in assembler? (visto che il compilatore C puo' benissimo generare
codice assembler anziche' direttamente codice macchina).
Io non dico che bisogna programmare SOLO in C, ma che non si deve
programmare SOLO in assembler altrimenti la manuntenibilita' del codice
va a farsi strabenedire.
Spero adesso di aver chiarito il mio punto di vista anche in rapporto
agli altri sottothreads =)
Saluti,
        Antonio

 va a farsi strabenedire.
Non e` detto. Inoltre, a volte, NON vi sono alternative, vedi PIC.
Tu stai confondendo le applicazioni, non si fa tutto con CPU
da 100MHz e MB di RAM, vi sono diversi livelli di scalabilita`.
Nel caso Arianne, magari il codice incriminato era di qualche
sottosistema
programmabile SOLO in assembly.
Se devo controllare una valvola, usando un PIC, mai e poi mai
sviluppero` in C, perche` il codice deve essere compatto, non posso
aggiungere memoria esterna, etc.
Il problema e` partito da un'affermazione che suonava:
"se avessero usato C...", IMHO non e` sempre possibile usare C,
vi sono NUMEROSI esempi di casi in cui non si puo` usare il C.


Guarda che non ci vuole molto a customizzare il gcc per poter generare
codice per dsp e microcontrollori.
Il compilatore di elezione per i dsp SHARC della A.D. e' infatti il g21k
vale a dire una evoluzione del gcc fatta apposta per generare codice per
quella famiglia di dsp, codice peraltro ultra-efficiente (come al solito
dipende da che tipo di compilatori usi, nel mercato dei dsp nessuno fa
caso alla qualita' del compilatore ragion per cui capita di trovar vere
schifezze ed esser portati a generalizzare).
Quanto ai diversi livelli di scalabilita' so bene che quasi sempre
bisogna ridurre tutto al minimo, ma anche in quei casi puoi e devi usare
il C (vedi sopra e mio post precedente).
Se poi non vi sono proprio altre strade si puo' sempre usare
l'assembler, ma non venirmi a dire che il codice rimane manutenibile,
basta che se ne vada chi l'ha scritto o passino un paio di anni senza
che ci lavori sopra e tutto viene perso.
Se a te va bene di scrivere software one-shot.....
Saluti,
         Antonio

 che ci lavori sopra e tutto viene perso.
Questo dipende da come e` fatto il lavoro, CVS e i commenti
si possono usare anche in assembly, certo che se si va di fretta...
Non e` che la manutentabilita` del codice derivi dal
fatto che e` scritto in C, deriva da come si imposta
il tutto, considera che anche Linux ha parti in assembly, eppure
e` il prodotto manuntentabile e migliorabile per eccellenza.
Certo che il C rende la vita piu` facile, a dirla tutta
il C non e` poi cosi` lento, se paragonato a Pascal o Fortran
o Ada. Fatto e` che, ripeto ancora, non sempre si puo` usare.
Sarei curioso di sapere come e` stato sviluppato il Tamagochi...


Allora correggo il tiro.
Su microprocessori con architettura avanzata, tipici di sistemi
general-purpose programmare direttamente in assembler non conviene. Le
architetture del processore possono essere difficilmente sfruttate
appieno da un codice assembler scritto a mano. Le cose di cui tener
conto sono molte e colmplesse, percui un compilatore puo` sopperire
facilmente "all'arte creativa umana" ottimizzando il codice in maniera
molto piu` efficente.
Quanto ai compilatori che non esistono per alcuni microprocessore
(tipicamente quelli dedicati a particolari scopi), scrivere un
compilatore e` abbastanza facile (o meglio adattarne alcuni). Il
compilatore puo` essere costruito poi per minimizzare la dimensione
del codice piuttosto che l'efficenza in esecuzione. Su questa
possibilita` non ho esperienze precise, ma sono abbastanza convinto
che questo approccio sia piu` competitivo della scrittura a mano del
codice. 
Aggiungiamo poi che l'assembler ha manutenibilita` e portabilita`
pressoche` nulla...


 BTW 90% e` una visione ottimistica, facile il 60-70%.
Tutto vero, ma le se le conclusioni spannometriche sono diverse e'
perche' tu hai in mente un DSP e non un ultrasparc o un PPC. Dato che la
discussione era generica, ho pensato che si parlasse di applicazioni
generiche...
Saluti
Lele

 generiche...
Si era partiti da Arianne 5, mi pare, credo che non abbiano P-II
a bordo, anche perche` troppo pesanti... E consumosi...
Probabilmente uC e DSP, comunque anche il SW per P-II ha
parti in assembly, le ISR..


 pressoche` nulla...
Portabilita` poca, manutentabilita` dipende, puo` esserci, bisogna
lavorare bene, con le idee chiare e senza troppi pasticci.


 compilatore non sa cosa vuoi ottenere dal tuo programma, tu sě.
Anzi, e' decisamente falso, qualsiasi coder di esperienza e' in grado 
di fare meglio di un compilatore.
P.S.: Tra 15 giorni parte il mio tentativo di realizzare un 
compilatore se qualcuno e' interessato a unirsi agli sforzi (lo scopo 
per ora e' didattico non vi aspettate di realizzae il nuovo Borland 
Builder).
Damiano Rullo
Trezzano S/N
Milan, Italy
http://members.it.tripod.de/Damianoux/index.html
mailto: 
d...@cheerful.com
mailto: 
dam...@mclink.it

 che ci mette 3 cicli..
Be qui' piu' che altro bisogna dare una martellata sulle gengive in 
primo luogo a chi ha progettato il DSP.
Come diavolo ha realizzato la divisione, credo che chiunque avrebbe 
fatto m=1/divisore, dividendo*m, senza bisogno di fare una scuola di 
ingegneria.


 ingegneria.
Se fai m=1/divisore fai comunque una divisione... :-)
Il pre-compilatore ed il compilatore dovrebbero essere abbastanza
scaltri da capire il trucco, fare la divisione ed usare la
moltiplicazione.
La divisione e` un'operazione notoriamente lenta...


compilatore se qualcuno e' interessato a unirsi agli sforzi (lo scopo 
E perche` mai? Cosa dovrebbe fare in piu` rispetto a gcc? Senza contare
il fatto che ci vorrebbero anni prima che arrivi al suo livello.


 di fare meglio di un compilatore.
Ohiohi!
Che ne dite di fare una gara... :-)
Sentite, ma credete che davvero un programmatore riesca a pensare a 18
flussi paralleli di istruzioni (quante sono le unità del
pipeline-farm-e quant'altro) che stanno dentro un processore tipo P2,
pensando a tutte le possibili permutazioni del codice intermedio, a
tenere in mente le catene delle definizione e degli usi di tutte le
variabili introdotte in un programma, senza parlare delle
ottimizzazioni piu' sofisticate tipo unfolding e smanettamenti vari
sugli stack (e le chiamate di procedura mediante scorrimento di
finestre sui registri come in alcuni risc)... Boh... a me e' venuto il
mal di testa solo a pensare cosa si puo' fare...
Inoltre, qualsiasi coder di esperienza non lo fa' perche' non e'
fesso...
se comunque ci riesce il processore per cui l'ha fatto e' uscito di
produzione da un paio di ere geologiche. (e comunque chi ha usato il
compilatore ha fatto gia' un pacco di soldi)
-- 
# Giorgio Vecchiocattivi.

 il fatto che ci vorrebbero anni prima che arrivi al suo livello.
:-)
per imparare principalmente.
Vedi, ho finalmente finito di studiare, il che vuol dire che mi resta 
un sacco di tempo libero (prima dovevo studiare e lavorare, adesso 
devo solo lavorare).
Mi sono guardato un po' in giro e ho visto che l'Italia per un ing. 
el. non e' certo la California, allora ho un paio di alternative:
O vado all'estero e vado a fare il lavoro che mi piace
O resto, faccio un'altro lavoro e imparo da solo.
Vorrei seguire la seconda strada visto che esistono una serie di tools
a basso costo per apprendere.
Ti espongo l'idea.
Nella fase 1 voglio apprendere molto sul progetto delle logiche 
digitali usando VHDL e le logche programmabili (FPGA in particolare) 
per sintetizzare i miei progetti, e apprendere molto sulla 
realizzazioe dei compilatori.
Nella fase 2 voglio provare a realizzare dei microcore di CPU RISC 
(esiste del codice rilasciato addirittura sotto GPL, quindi di 
materiale per imparare ce n'e').
Sempre nella fase 2 voglio provare a realizzare dei piccoli 
compilatori per i miei chip.
Nella fase 3 voglio creare sistemi integrati onchip, cioe' piu' 
dispositivi su un singolo chip che facciano cose utili, tipo 
interfacciarsi al TV di casa o alla linea telefonica. Piccole reti 
neurali in grado di apprendere operazioni semplici.
Nella fase 4 posso pensare alle eventuali applicazioni commerciali dei
chip, a licenziarne il codice, e al passaggio da FPGA ad ASIC.
Nella fase 5 avremo una parte analogica e una parte digitale sullo 
stesso chip, per applicazioni di vario genere (principalmente sensori 
intelligenti) e probabilmente anche una o piu' reti neurali per 
applicazioni di pattern recognition.
Resta bene inteso che:
Chiunque voglia unirsi all'impresa e' il benvenuto, a patto che sia 
ben chiaro che per anni si tratta di studiare duro nel tempo libero 
senza ricavi.
Se vuoi fare un porting di GNU gcc per i chip e' molto gradito, pero' 
forse il gcc e' un po' troppo, basta un compilatore c, puoi magari 
orientarti su lcc, o usare i tool che uso io per decrivere la sintassi
del C e generare il parser, personalmente non sono riuscito a reperire
un parser per ANSI C, se sai dove trovarlo ...
Personalmente lo faccio perche' comunque anche se non dovesse sfociare
in qualcosa di commerciale ho comunque un grande interesse per queste 
cose nel loro insieme, e anche perche' avere esperienza di progetto su
FPGA e ASIC e' qualcosa che presso le aziende di elettonica vale tanti
soldi.
Per quanto riguarda il compilatore di cui parlavo all'inizio, sara' un
compilatore basic non C. Ma un basic strutturato, per molti versi 
simile al pascal e al C, ma con una sintassi molto semplice.
Lo scopo e' avere codice molto compatto, quanto il C almeno, per le 
MCU a 8/16 bit. e far programmare i microcontroller anche a chi non ha
voglia di imparare il C o lo ritiene complesso, non tutti quelli che 
sviluppano schede elettroniche sono abili coder.
Visto che siamo in ambito S.O. dibattiti quello che gradirei avere per
i miei chip e' un piccolo RTOS multitasking, per cui anche lo studio 
delle architetture di piccoli S.O. multitask rientra nei miei piani.
Per il momento ne ho trovato uno di circa 16 K per 8086, ma ha qualche
problema a compilare nella parte C (!?), mentre l'assembler compila 
correttamente.
Le prime esperienze si potrebbero fare sui microcontroller esistenti 
(pensavo soprattutto AVR o Hitachi H8).
Chiunque abbia esperienza in tal senso e' graditissimo se vuole unirsi
al progetto.
Molto presto preparero' un sito su Internet e ne daro' infromazione 
nei newsgroup.
Per il momento sto facendo il porting dei tool che usero' sotto OS2.
Ciao.


 Se fai m=1/divisore fai comunque una divisione... :-)
Si, ma dovendo fare solo quella si potrebbe pensare di ottimizzarla.
Ad ogni modo quella di invertire le costanti e moltiplicare e' 
un'ottimizzazione che si e' sempre fatta quando si scrive il codice, 
nel dubbio se il compilatore lo faccia o meno, cosi' come calcolare le
costanti al di fuori dei cicli.


 mal di testa solo a pensare cosa si puo' fare...
Il fatto e` che non ci riesce neanche il compilatore, chi pensi
che lo abbia scritto (il compilatore)? Sempre uomini...


 che lo abbia scritto (il compilatore)? Sempre uomini...
No, i compilatori possono farlo e lo fanno (non sempre a dire la
verita`). Posso scrivere un programma che calcola 500.000 cifre di
pigreco ma non credo che io possa essere in grado di farlo a mano. 
-- 
# Giorgio Vecchiocattivi.

 pigreco ma non credo che io possa essere in grado di farlo a mano.
Qui sta l'errore! Calcolare PI e` un compito "sistematico", cioe` si
applica
un algoritmo.
Per i compilatori e` diverso, il problema nasce dal fatto che il
compilatore
non sa cosa l'utente vuole fare, l'ottimizzazione e` locale, tanto
locale
che non sempre e` ottimizzazione.
E` vero che un uomo ha difficolta` a tener traccia dei pipeline &
parallelismi
vari, ma e` anche vero che questa e` solo la seconda parte che il
compilatore deve svolgere.
Inoltre i vari Pentium hanno un HW instruction reordering (che i VLIW
non
hanno), mi pare con finestra di 56 istruzioni.
Comunque sia, il compilatore usa anche tecniche euristiche per
ottimizzare
il codice ed e` proprio qui che fallisce miseramente.
Questo porta conseguenze sulla seconda parte, ovvero la gestione dei
vari pipeline.
Un esempio: il cuore di Quake e` stato scritto in assembly, ottimizzato
per l'unita` FP del Pentium, cioe` hanno tenuto conto a mano dei
pipeline...
Poi dipende dall'applicazione, un controllo PID scritto in assembly per
DSP e` SEMPRE due volte piu` veloce e compatto della versione C.
Questo perche` vi e` una grande differenza tra il linguaggio C e`
l'assembly
del DSP.
Se vogliamo la capacita` di ottimizzare di un compilatore e`
inversamente
proporzionale alla distanza fra i linguaggi...
Per la rete neurale che abbiamo in testa, questa distanza e`
aggirabile...


 proporzionale alla distanza fra i linguaggi...
Mah... io non la metterei cosi`. D'altronde TUTTI i compilatori poi
alla fine ottimizzano il codice intermedio, che piu` o meno e` uguale
per tutti. Sia per un linguaggio funzionale che imperativo.


provare a compilarlo, facciamo dei confronti. 
Non voglio sconvolgervi, ma Quake e' stato sviluppato sul Next, ed
tutto C.
Quake2 e' stato scritto sotto WinNT sotto Intel, ma e' stato
ricompilato anche per SPARC ed Alpha.
A dire il vero quelli della id Software (o meglio *quello) sono tra i
pochi sviluppatori di videogiochi a pensare alla compatibilita'
multipiattaforma.
Quake3 uscira' contemporaneamente per Windows, Macintosh e Linux.
dd
--
To reply replace "xx" with "mc"

 per tutti. Sia per un linguaggio funzionale che imperativo.
Il problema e` che il compilatore NON ha una analisi semantica del
linguaggio, ma solo sintattica.
Vedi esempio sopra, oppure:
if (x < 0) x = x + 64;
if (x > 63) x = x - 64;
supponendo che x non venga mai incrementato troppo.
Alternativa:
x = (x + 64) & 63; 
Direi molto piu` veloce la seconda, specie su processori pipelined.
La seconda e` molto piu` vicina all'assembly della prima, e`
praticamente assembly...
Chiaramente mi aspetto che il compilatore faccia il suo dovere nel
secondo caso...
Magari:
x += 64;
x &= 63;
funziona meglio... Ancora piu` assembly...
Ancora, su di un MC68000, supponiamo di dover trasferire 256 word (16),
tipico accesso ad HD IDE.
E` forte la tentazione di definire un array di 256 short int, ma
funziona
meglio (piu` velocemente) se si definisce una array di 128 long int.
Questo lo puo` sapere solo chi conosce HW/SW del MC68000, di certo non
lo sa il compilatore... Che neanche ci prova a contraddire il sorgente
C...


 tutto C.
A me non risulta affatto, forse ti stai confondendo con
un altro gioco.
Tra l'altro ci si chiedeva come mai non fosse cosi` veloce su di un K6,
il motivo era proprio l'ottimizzazione per Pentium.


 tutto C.
Mi sembrava strano....


il motivo era proprio l'ottimizzazione per Pentium.
No, il motivo era l'unita' in virgola mobile delle CPU AMD, che
notoriamente e' meno veloce di quelle Intel.


 notoriamente e' meno veloce di quelle Intel.
Per via del pipeline, appunto.
L'unita` FP del Pentium esegue "bene" istruzioni FP in sequenza,
quella del K6 esegue "bene" istruzioni FP in parallelo con istruzioni
integer e (credo) data move.
Quelli di Quake si sono preoccupati di mettere le istruzioni FP
in sequenza, mentre, di solito, si tende ad usare la soluzione di AMD.
Questo perche` molti processori, fino a qualche tempo fa, erano in
grado di eseguire istruzioni "diverse" in parallelo.
L'innovazione di Intel e` stato proprio quella di spingere
l'unita` FP oltre quelle che erano le normali concezioni
dell'epoca, cioe` di usare un'architettura pipeline anche
per quella parte del processore.


 C...
I casi sono due. O uno lo sa`. O uno non lo sa`. Se lo sa dice al
compilatore di usare long int. Se non lo sa usa gli short. Anche se
scrive in assembler. Comunque credo che succeda una cosa del genere
anche sul PPro. Ragion per cui nel sorgente di linux c'e' un apposito
cast nella funzione strcpy.
Salut. (belli i disegnini eh?)
PS Spero che intuisca che faccio questa "guerra di religione" per
passare il tempo... 


 passare il tempo...
Finche` il tono rimane di semplice discussione non ci sono problemi,
si impara sempre qualcosa.
Il problema e` che a volte si trova gente che, in mancanza di
argomentazioni, inizia ad offendere.


 wrote:
[ snip ]
DD>Non voglio sconvolgervi, ma Quake e' stato sviluppato sul Next, ed
DD>tutto C.
Sicuro ? Anche io avevo sentito che era /tremendamente/ ottimizzato
(a manina ;) per la FPU del Pentium. Questo era anche il motivo per
cui non 'rendeva' sotto AMD.
A proposito, non e' che ti confondi con DOOM ? Mi ricordo di un 
articolo in cui si diceva che quest'ultimo era tutto scritto in
C e sviluppato sul Next...coincidenza ? ;)
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

un altro gioco.
No, non si confonde.


 No, non si confonde.
Come da una news seguente:
"forse vi confondete con Doom"


C e sviluppato sul Next...coincidenza ? ;)
Certamente no.
Il Next fu usato sia per Doom che per Quake.
John Carmack passo' al Visual C++ su Windows NT per Quake2.


   anche Linux ha parti in assembly.
Linux e' sviluppato da centinaia di persone, i programmatori di
doom/doom2/quake/quake2 non sono mai stati piu' di tre o quattro.
Anzi il responsabile dei port di quake2 verso alpha/NT, x86/Linux,
x86/Solaris, SPARC/Solaris, nonche' delle varie patch della versione
principale nel corso del 1998 e' stato uno solo.
Gli altri tre stavano sviluppando Quake3.
Dubito che tutti quei port sarebbero stati possibili se Quake non
fosse stato scritto avendo come uno dei suoi obbiettivi la
portabilita'.
Ah, quasi mi stavo scordando: tutta la parte di meccanica del gioco in
Quake in effetti non e' scritta in C.
E' scritta in QC ! Un linguaggio sviluppato dalla stessa id Software,
che (se non erro) veniva compilato in pseudoassembler ed interpretato
a runtime.
Con Quake2 passarono a delle DLL esterne scritte in C, di cui
rilasciarono il codice per permettere delle modifiche scritte dagli
utenti.
Ecco un estratto del plan file di John Carmack, coproprietario e
programmatore capo della id Softwrae (la cui lettura e' abbastanza
affascinante per un programmatore):
============
2/8/98
I have been meaning to do something for the FSF for a long time. Quake
was deployed on a dos port of FSF software, and both DOOM and Quake
were developed on NEXTSTEP, which uses many FSF based tools. I don't
subscribe to all the FSF dogma, but I have clearly benefited from
their efforts.
============


"forse vi confondete con Doom"
Come gia' risposto, no.
A questo punto, potresti fornirmi la fonte delle tue informazioni su
"il cuore di Quake scritto in assemby, ottimizzato per l'unita' FP del
Pentium" ?
Rilenggendo tutte le informazioni rilasciate dal programmatore capo di
Quake che sono riuscito a recuperare non ne ho trovato traccia.
Non e' che si trattava di una dichiarazione stampa di AMD ? :-)


 ============
Nulla toglie al discorso dell'ottimizzazione Pentium, forse
hanno fatto un po' di profiling ed ottimizzato quello che
c'era da ottimizzare in assembly.


 Quake che sono riuscito a recuperare non ne ho trovato traccia.
Sempre Carmack.
Magari l'ottimizzazione e` stata fatta dopo aver fatto il porting.
Non mi stupirei se avessero valutato dove il motore perdeva piu`
tempo (profiling) e riscritto quelle (poche) parti di codice in
assembly, magari anche non pensando al pipeline della FP, in principio.
Cerchero informazioni.


Penso non abbia problemi a fare il porting... :-)
No, Dave Kirsh ("zoid")
Carmack e gli altri due stavano (stanno) scrivendo Quake3 :-)


>cui non 'rendeva' sotto AMD.
DD>Ottimizzato a manina per il Pentium mentre veniva sviluppato su una
DD>Nextbox ? Impressionante.
Dalla Nextbox lo hanno passato su Intel, giusto ?
C'e' un articolo interessante di M.Abrash, sul Dr.Dobb's Sourcebook 
n.259, intitolato "Floating-point for Real-Time 3D", in cui l'autore, 
prima di lanciarsi in una descrizione della FPU del pentium e di 
illustrare una serie di ottimizzazioni, scrive testualmente:
"Quake, the game I'm currently working on, uses FP all the way down
 into the inner loop of the span rasterizer, performing several FP
 operations every 16 pixels".


 operations every 16 pixels".
OK, ritirata strategica su posizione arretrata: ;-)
Quake e' stato effettivamente sviluppato in C, su di un altro
processore, e con l'intenzione di renderlo portabile. In un secondo
tempo sono state introdotte ottimizzazioni specifiche per il Pentium.


 No, Dave Kirsh ("zoid")
Non credo neanche lui abbia problemi... :-)


 tempo sono state introdotte ottimizzazioni specifiche per il Pentium.
Come sempre si impara qualcosa!
Io, che Quake e` stato sviluppato su Next. Tu, che poi lo hanno
ottimizzato per Pentium.


essentially identical on all platforms.
Quindi Quake (1) ERA ottimizzato a mano nella parte di visalizzazione.
Poiche' adesso la visalizzazione e' interamente affidata ai driver
Open GL le ottimizzazioni non ci sono piu'.
