Newsgroup: it.comp.lang.c++
Titolo: Ciclo infinito

Il titolo sembra un po' masochista, ma mi chiedevo se si poteva far
girare un ciclo all'infinito, senza però fermarsi su quella parte del
corpo del programma. Cioè mentre il programma gira normalmente c'è un
qualcosa che si ripete n volte o infinite (ad esempio fare una scritta
lampeggiante in dos...)

 ha scritto:

Il modo piu' semplice e' far girare un task separato. Se sviluppi su Windows ci sono i thread.
Antonio

Antonio Donatiello wrote:

I thread ci sono anche in altri S.O...basta che siano multitasking...ad esempio Windows3.1x non lo
era...
At salud

 Antonio
ehm... che sarebbe un task (io parlo sempre di dos). Un piccolo esempio...

>era...
Non capisco il tuo tono polemico. Io non ho detto che gli altri SO non lo siano, ma ho voluto solo dare un'indicazione a chi molto probabilmente sviluppa per Windows.
E poi, scusa tanto, ma chi se ne frega se Windows 3.1x non aveva i thread. Siamo a Windows 2000 se non lo sai!
Antonio

 ha scritto:



oserei dire PURTROPPO!!!
io spero presto di tornare a lavorare su UNIX...quella si che era una piattaforma affidabile!
PS: so di avere scatenato un thread di discussione su "vecchio e nuovo che <avanza>" (nel senso che e' di troppo!)...
Saluti

 ehm... che sarebbe un task (io parlo sempre di dos). Un piccolo esempio...
non sono un esperto,ma credo sia difficile creare un task separato in DOS....
molto difficile!

>io spero presto di tornare a lavorare su UNIX...quella si che era una piattaforma affidabile!
Lo spero anche io.
Vai a dire che Unix e' affidabile ai miei ex colleghi del Sanpaolo dove 3 server unix in configurazione fault tolerance (non mi chiedere i dettagli - non li conosco) andavano in crash tutti e 3 (sono stati sostituiti con dei server NT!).
Antonio

Antonio Donatiello <ant...@REMOVETHISgeminisoft.com> wrote in message
10ld8vf$osd$1...@fe2.cs.interbusiness.it...
Vai a dire che Unix e' affidabile ai miei ex colleghi del Sanpaolo dove 3
server unix in configurazione fault tolerance (non mi chiedere i dettagli -
non li conosco) andavano in crash tutti e 3 (sono stati sostituiti con dei
server NT!).
Un sistema Unix richiede una cura nella configurazione dei singoli elementi
molto complessa. Se alcune configurazione erano sbagliate o rattoppate....
La stessa cosa può accadere con NT, solo che NT è molto più facile da
configurare e gestire, anche se spesso ti permette di fare meno cose
rispetto a ciò che si potrebbe fare con Unix.
--
| /
| \Byte - Andrea Briganti
E-Mail 
kbyt...@freemail.it
ICQ 40872731

>rispetto a ciò che si potrebbe fare con Unix.
E viceversa. NT e' molto sottovalutato. In un recente test su PC professionale NT ha strabattuto tutti gli altri come Web Server quando si tratta di eseguire applicazioni che generano pagine dinamiche.
Antonio

Mmmh... Date un occhio (anche se siamo completamente OT)
http://www.unix-vs-nt.org/
Mi rendo conto di essere di parte, ma mi trovo a piangere in cinese per
le conseguenze di aver scelto NT come sistema operativo per un server
mission-critical. Basterebbe menzionare il fatto che senza prodotti
aggiuntivi mi toccherebbe fare mezzo chilometro a piedi per lavorare sul
server, che pure e' connesso via LAN...
Ciao,
Nicola

Dimenticavo: la scelta non l'ho fatta, l'ho subita...
Ciao,
Nicola

>server, che pure e' connesso via LAN...
In effetti sei di parte. Per amministrare NT devi avere NT workstation oppure installare su 95/98 l'estensione (sempre Microsoft) per l'ammiinistrazione remota. Adesso mi sfugge il nome. Tra l'altro NT adotta anche lo standard SMNP per il monitoraggio del sistema.
Antonio

Gia', ma con NT da solo ci faccio molto poco. Per l'esecuzione di molti
comandi devo trovarmi sulla console. NT non mi da strumenti di scripting
decenti, non mi permette di aprire sessioni remote sul sistema per
eseguire i miei comandi, non ho "cron" per eseguire comandi ad
intervalli specificati e la lista prosegue...
Per esempio la gestione di un database complesso non puo' prescindere da
questo tipo di strumenti.
Esiste poi tutta una serie di operazioni di configurazione che impongono
il reboot del sistema, cosa che molto spesso su Unix non e' necessaria.
Conclusione: nella mia esperienza trovo NT insuperato per piccoli
uffici, dove qualche PC accede al server centrale per i dischi
condivisi, il backup, le stampe e poco d'altro. Per compiti mission
critical non e' all'altezza.
Ciao,
Nicola

>critical non e' all'altezza.
Punti di vista, comunque ti consiglio di leggere il test su PC professionale di Ottobre 99 (mi sembra) dove NT stravince contro tutti gli altri come WebServer sulle applicazioni di commercio elettronico (pagine HTML prodotto dinamicamente da applicazioni). L'accopiatta Linux/Apache esce con meta' delle prestazioni di NT.
Antonio

 decenti,
Chiedo scusa, ma Windows Scripting Host e` PERFETTAMENTE
decente, soprattutto considerando che fra i moltissimi linguaggi
di scripting che ospita c'e` anche il *Python*!-)
Sul resto penso che tu abbia pienamente ragione, ma su questo...!!!
Alex

Antonio Donatiello <ant...@REMOVETHISgeminisoft.com> wrote in message
10lne17$gm3$1...@fe2.cs.interbusiness.it...
E viceversa. NT e' molto sottovalutato. In un recente test su PC
professionale NT ha strabattuto tutti gli altri come Web Server quando si
tratta di eseguire applicazioni che generano pagine dinamiche.
Si vero, ma ciò è dovuto allo sviluppo più lento in questo campo delle
applicazioni unix.
Però da quanto ne so io Unix a differenza di NT riesce a gestire e
sopportare un carico di connessioni contemporanee molto più elevato.
Vedi Atlantide nella sezione dei nick e profili che gira con NT e pagine
dinamiche collegate a un database....


>dinamiche collegate a un database....
Allora mettiamo in discussione i test e diciamo che un caso e' quello che ci va bene.
In questa ottica Dell per la vendita online dei pc (e penso che nessuno batta Dell in questo senso) ha macchine NT.
Comuqne la discussione di partenza era un'altra e ho paura che stiamo diventando OT.
Antonio

Antonio Donatiello <ant...@REMOVETHISgeminisoft.com> wrote in message
news:879eq1$91i$1...@fe1.cs.interbusiness.it...
"Kbyte" <kbyt...@NOlibero.itNO> ha scritto:
: >>Si vero, ma ciò è dovuto allo sviluppo più lento in questo campo delle
: >>applicazioni unix.
:
: A dire il vero i motivi sono:
: - ISAPI e' molto piu' leggero di CGI;
Certamente.  Appunto per questo, nessuno che voglia un sistema _altamente
scalabile_ basato su applicazioni che generano dinamicamente delle pagine
si sognerebbe neppure di usare il CGI: userebbe invece PyApache, o mod_perl,
o le Python-Server-Pages (come descritte nell'ultimo Dr Dobbs), o una
qualsiasi
delle mille altre soluzioni analoghe.
: - i thread di NT sono piu' leggeri dei processi di Linux;
Vero, ma anche su Linux si possono usare i thread, e piu` performante (e
scalabile) ancora e` non usare nessuno dei due (su una macchina uni-CPU,
vedi oltre).  Infatti il server di rete dalle prestazioni/scalabilita` piu`
incredibili
e` Medusa, basato appunto su questo concetto (multi-tasking _cooperativo_,
"ad eventi", entro lo stesso thread, invece che multi-threading o peggio
ancora
multipli processi; a thread "di servizio", forniti "di nascosto" dal motore
Medusa,
si delegano solo i compiti di sistema che sarebbero altrimenti "bloccanti",
cioe`
in pratica il solo nudo I/O).
: - Linux non scala bene su piu' processori ed infatti pare che sara'
rilasciata
: una nuova versione che andra' meglio in questo senso.
Questo e` interessante ed importante.  Era sicuramente vero tre anni fa,
quando mi occupavo attivamente di Linux, ma gia` allora si parlava di
modifiche al kernel per risolvere il problema; curioso che nonostante cio`
sia ancora vero adesso.
: >>Però da quanto ne so io Unix a differenza di NT riesce a gestire e
: >>sopportare un carico di connessioni contemporanee molto più elevato.
:
: Il test di PC professionale era proprio fatto simulando un carico di
richieste provenienti da piu'
: client. Vinceva chi : riusciva a soddisfare piu' richieste all'aumentare
dei client. Dopo un certo
: numero di client le prestazioni di Linux (ma anche di altri sistemi) si
appiattivano mentre quelle
: di NT salivano fino a quasi il doppio.
Se gli "altri sistemi", come hai indicato, usavano CGI, c'e` poco da
stupirsi; e`
allora solo un test mal progettato, che paragona lucciole con lanterne.
Se le specifiche richiedono CGI, si paragoni CGI sulle diverse piattaforme
(eventualmente, Fast-CGI, che qualche vantaggio lo ha pur restando "in
sostanza" CGI); se richiedono pagine generate dinamicamente con una
qualsivoglia tecnologia, si possono allora paragonare ISAPI e mod_perl o
altri simili schemi.  Se poi la scalabilita` e` tutto, anche Medusa va messo
nel confronto.
Alex

>nel confronto.
Non ho sottomano la rivista (e' a casa). Tra l'altro e' di Settembre 1999 e non di Ottobre come avevo precedentemente indicato.
Il test non era fatto usando CGI per gli altri e ISAPI per NT, ma con la tecnologia piu' adatta al server utilizzato. Addirittura (sempre a detta di PC professionale - tra l'altro i test sono stati fatti dalla cugina americana) le macchine ed i Web Server (software intendo) sono stati calibrati con l'aiuto dei fornitori.
Il test ha riguardato pagine statiche (non vinceva NT ma mi sembra SUN / ???), pagine dinamiche e pagine dinamiche con SSL.
Medusa non mi sembra fosse tra quelli testati.
Sempre se non ricordo male una nuova versione di Linux non era stata "testabile" perche' lo stack tcp/ip di quella versione aveva problemi con i client Windows utilizzati.
Vorrei chiarire, se ce ne fosse bisogno, che io non conosco Linux mentre conosco abbastanza bene i sistemi Windows ed in questo caso ho cercato di riportare fedelmente (a memoria) quello che ho letto riguardo il test su PC professionale.
D'altronde la discussione Linux / NT appassiona quasi quanto quelle su destra-sinistra. Ma questa e' un'altra storia.
Antonio
PS: per chi non crede ancora a NT come web server, consiglio di andare a vedere le statistiche su 
www.netwatch.com
; NT ne ha circa la meta di Linux.

C'e' un equivoco di fondo dietro ad alcune delle affermazioni espresse
in questo thread (non necessariamente nel messaggio a cui mi aggancio),
ovvero che Linux e Unix siano sinonimi (ovvero che PC e computer siano
sinonimi).
Parlando di sistemi mission critical (e sono tuttora convinto che la
scelta di NT in questo campo sia suicida, si veda per l'appunto
http://www.unix-vs-nt.org/
 ) il mondo Unix mette a disposizione una
varieta' di soluzioni che permettono un livello di scalabilita' che NT
manco si sogna.
A proposito poi di cosa viene usato in giro, vi suggerisco di dare
un'occhiata qui: 
http://www.netcraft.com/survey/influence.html
Saluti,
Nicola

: di NT salivano fino a quasi il doppio.
Si, peccato che quelli di PCUNprofessionale siano pagati da m$ per
dire certe cose...
--
 (o-  | c:\> win2000patch001.exe
 //\  | This Microsoft(c) patch fix all bugs present. All rigth reserved.
 V_/_ | Insert Linux boot disk to continue ... loading kernel ...
http://pinguin.linuxbox.com
 r.salmaso(at)
flashnet.it

destra-sinistra. Ma questa e' un'altra storia.
Non c'e' storia: vince linux ^_^
Ma it.comp.lang.c++ non e' il gruppo piu' adatto, e' meglio
it.comp.os.dibattiti


>E viceversa. NT e' molto sottovalutato. In un recente test su PC
professionale NT ha strabattuto tutti gli altri come Web Server >quando si
tratta di eseguire applicazioni che generano pagine dinamiche.
Attenzione, che nel test era riportato chiaramente che i risultati erano un
po' falsati a favore di NT. (forse non avevano installato la versione piů
recente su Linux mentre l'avevano fatto per NT, o qualcosa di simile,
confrontare prodotti di diverse "annate" non ha molto senso, data
l'evoluzione continua che questi prodotti subiscono).
Nonostante questo, mi pare che le prestazioni fossero molto simili.
--
Alessandro Monti

 dire certe cose...
Ne dubito davvero.  E` una rivista decente, e non avrebbe senso
che si bruciasse il paglione per due cents (per non dire di rischiare
la galera nelle cause antitrust -- non so se l'hai notato, ma i nemici
di MS sono assai agguerriti in tribunale).
Alex

 tutto il resto).  V. 
http://aleax.supereva.it/
 per altre informazioni.
Purtroppo ne sento parlare spesso, e dopo aver letto le tue
traduzioni su Python continuo a non capire quest'enfasi.
Saresti cosi cortese da fare qualche piccolo (minuscolo) esempio
che possa giustificare l'uso di Python al posto del C++???
Qualcosa che riguardi la semplice semantica e non le librerie che 
lo corredano.
Fausto

Stai scherzando spero. Le prestazioni di IIS erano quasi doppie di quelli
di Stronghold (si scrive cosi?) sulle pagine dinamiche >con SSL. Come ho
detto in un altro post tutte le versioni del sistema opeartivo e del web
server erano le ultime e installate con
Ah, beh. Su un compito specifico forse. Non ho sottomano l'articolo, ma mi
"pare" proprio di ricordare che il succo era che sono prodotti più o meno
equivalenti.
O forse ricordo proprio male :-(
--
Alessandro Monti

 lo corredano.
Il rapporto fra il numero di righe di codice necessarie in
Python e in C++ per svolgere un determinato compito (a
parita`, grosso modo, di chiarezza e linearita`, anzi con
un discreto vantaggio per il Python -- non e` certo un
linguaggio "write-only") e` di circa dieci a uno.  Lo stesso
rapporto, grosso modo, si applica dunque ai tempi di
sviluppo/debug/manutenzione/miglioramento (che in
realta` crescono piu` che linearmente con la dimensione
del codice, ma supponiamo di stare usando in entrambi
i casi una eccellente strategia "a componenti" in grado di
minimizzare questa malnata non-linearita`).
E` strana la tua richiesta di non usare le librerie standard
di un linguaggio assieme al linguaggio stesso.  Perche` non
dovrei usare std::map in C++, visto che e` parte delle "librerie
che lo corredano"?  Mentre potrei usare gli equivalenti dictionaries
in Python, visto che fanno parte del linguaggio piuttosto che non
delle sue librerie standard?  O similmente, perche` dovrei poter
usare le regular expression in Perl (che le incorpora nel linguaggio
vero e proprio) e non in Python (dove sono nella libreria standard,
nel senso che occorre un "import re" per averle a disposizione)?
Questo peculiare vincolo sembra pensato per favorire quei linguaggi
che fanno la strana scelta di "incorporare tutto e mezzo" nel
linguaggio vero e proprio (a prezzo magari di sintassi contorte),
tipo Cobol o Perl, a danno di quelli che seguono la preferibile
strategia di mantenere il linguaggio relativamente sgombro e
mettere le funzionalita` piu` importanti nelle librerie standard del
linguaggio stesso (come C++, Python, e Java).  Forse la ragione
stessa per l'esistenza di linguaggi cosi` oberati (di funzionalita`
che starebbero molto meglio in librerie standard "a corredo" del
linguaggio) e` almeno in parte proprio nel fatto che la gente fa
richieste cosi`!!!-)
Comunque, visto il tuo vincolo: considera qualsiasi cosa che in
C++ faresti con std::vector, std::map, eccetera; visto il tuo
vincolo di non usare le librerie, pensa che fatica dannata sarebbe,
in pratica, riscriverti tutte le librerie stesse ogni volta nell'ambito
del tuo stesso programma.
Le cosiddette "liste" e "dizionari" del Python sono in pratica del
tutto equivalenti a vector e map (e sono parte del linguaggio vero
e proprio, non delle sue librerie) e quindi ti garantirebbero un
grosso aumento di produttivita` (sostanzialmente lo stesso che
otterresti _togliendo_ lo strano vincolo "non usare le librerie
standard del linguaggio").
Peggio, pensa all'I/O: come faresti I/O in C++ senza le librerie?!
C'e` da rabbrividire veramente...
Togliendo ad entrambi i linguaggi lo strano vincolo, il rapporto
di produttivita` non cambia, perche`, se il C++ guadagna l'I/O
e ragionevoli strutture dati, il Python guadagna molto altro.
Prendiamo un tipico esempio, un prototipetto che mi sono
scritto di recente.  Voglio permettere all'utente di smazzare
mani di bridge, accettando solo quelle che soddisfano certi
vincoli da lui scelti.  E` un problema risolto di frequente in
C, o C++ (
http://www.best.com/~thomaso/bridge.html
,
http://www.dombo.org/henk/dealer.html
), incorporando un
linguaggio ad-hoc (la scelta di Dealer) ovvero un linguaggio
di scripting (la homepage di Thomas Andrews ad esempio,
la prima delle due URL teste` citate, contiene puntatori a
programmi fatti per usare allo scopo il linguaggio TCL).  Se
si usa un linguaggio gia` esistente, le cose migliorano, ma
se no stiamo parlando di una decina di migliaia di righe di
C o C++ (usando lexx e yacc o simili per il linguaggio ad hoc;
di piu`, ovviamente, se si vuole "far tutto in casa") per un
decente minimo di funzionalita` (anche il codice di Andrews,
che usa TCL, ha decine di migliaia di righe di codice, ma esso
offre _ben piu`_ del "minimo decente", in termini di funzioni
offerte all'utente finale).
Ho fatto un prototipo di questa funzionalita` in Python.  150
righe di codice (leggibili, strutturate, commentate) per un
"minimo decente" di funzionalita` o poco meno (lunghezza
dei colori, conto dei punti, punti e simili valutazioni in un dato
subset di colori, ...).  Anche la generazione dei numeri casuali
e` in Python (il generatore incorporato, come ahime` e` tipico
dei generatori acclusi nei vari linguaggi, e` di bassa qualita`
statistica) -- una implementazione del "Mersenne Twister"; di
norma si userebbe ovviamente un componente scritto in un
linguaggio compilato per questo compito (di basso livello, non
soggetto a incognite di sviluppo, e tale da impegnare la gran
parte della CPU utilizzata), ma avevo sotto mano l'implementazione
Python, e non mi interessavano le prestazioni -- ma questo non
e` un caso tipico, eccetto che nelle prime fasi di prototipazione.
(Le prestazioni dell'implementazione "100% Python" risultano
infatti scarse, e facilmente si migliorerebbero semplicemente
usando un componente Mersenne Twister scritto in C o C++).
Qui il rapporto e` ben superiore a un ordine di grandezza, e
sfiora i _due_ ordini di grandezza, ma e` naturalmente perche`
in questo caso stiamo sfruttando (cosa non del tutto tipica,
benche` non poi cosi` rara) tutta l'intelaiatura del Python stesso
come "linguaggio di scripting messo a disposizione dell'utente
finale".  Se nell'implementazione C++ immaginiamo di riusare
un linguaggio tipo TCL, torniamo piu` vicino all'ordine di
grandezza (fattore 10) che ai due ordini di grandezza.
Un altro esempio (sempre relativo al bridge, ma di tutt'altra
natura) -- il calcolo combinatorio delle probabilita` di divisione
dei colori nel corso del gioco (utile per l'analisi a posteriore).
In questo caso, il vantaggio viene dal fatto che, in Python,
esistono come parte del linguaggio i "long" -- interi con un
numero illimitato di cifre.  Di conseguenza, il calcolo del
fattoriale di 52, e simili, e` banale; in poche decine di righe
si esprime facilmente tutto l'algoritmo nel modo piu` chiaro
e lineare (compresa la tipica ottimizzazione "memoize", un
idioma che d'altronde e` comune e prezioso anche in C++
per compiti del genere).  In C++, occorre praticamente
definirsi un tipo "intero con numero illimitato di cifre" e
tutte le relative operazioni (la divisione e` la peggio... ma,
ahime`, le probabilita` sono definite appunto come risultato
di simili divisioni fra casi possibili e casi favorevoli!).  Anche
in questo caso si "sfora" di non poco l'ordine di grandezza
(uno furbo, naturalmente, aggirerebbe il problema riusando
una libreria gia` esistente per questo compito, ma questo
e` piu` o meno sempre vero, cioe` si applica uniformemente
ai due linguaggi e non altera il "rapporto di potenza" fra
essi).
Questo piccolo motore di calcolo l'ho fatto per usarlo in una
CGI allo scopo, appunto, di mostrare ai visitatori le varie
probabilita` condizionate.  Lo stesso script CGI usa anche,
naturalmente, il modulo standard CGI del Python, che come
e` ovvio risolve tutti i problemi di acquisizione di dati dalla
form, ecc ecc; e un altro moduletto che ho scritto io, per
la funzione di "template" (cosi` da poter generare in modo
uniforme, da un file HTML con opportuno markup, le pagine
di risultati, che funzionano anche come form per ripetere
la query con altri parametri, in vari linguaggi).  Ciascuno
dei moduli e`di poche decine di righe di Python, e in tutto
sono 4 moduli.  Anche qui, parliamo di _almeno_ un ordine
di grandezza di risparmio rispetto al fare il tutto in C++
(ho una implementazione C++ delle stesse funzionalita`,
fatta un paio d'anni fa [prima di scoprire Python], che usa un
dialogo Windows invece delle form HTML [quindi non puo`
girare in rete], eppure gia` 'sfonda' il solito rapporto di ordine
di grandezza...).
Il C++ e` un ottimo linguaggio _per i compiti a lui propri_:
soprattutto la scrittura di codice *estremamente efficiente,
estremamente veloce*.  E` il mio linguaggio preferito per
scrivere quei componenti di basso livello e altissime
prestazioni che sono poi "incollati" da un linguaggio di
livello superiore per formare il complesso dell'applicazione
(l'esempio suvvisto di calcolo delle probabilita` e` atipico,
non contenendo componenti C++ ne` sentendone alcun
bisogno; quello della generazione di smazzate e` piu`
tipico, trattandosi di _prototipo_ che attualmente usa solo
componenti in puro Python ma alcuni dei quali sono di
certo _destinati a migrare_ a C++ per chiarissime ragioni
di prestazioni).
Alex

>O forse ricordo proprio male :-(
La seconda che hai detto.
Il test sulle pagine dinamiche e' quello piu' complesso perche' vengono eseguite applicazioni. Il test con SSL e' ancora piu' complesso e si fa perche' alcune applicazoni devono essere "sicure" come ad es. il commercio elettronico.
Sulle pagine statiche come ho gia' detto IIS non era il primo ma il secondo dopo Sun e Linux era sempre parecchio dietro.
Antonio

 In questa ottica Dell per la vendita online dei pc (e penso che nessuno
batta Dell in questo senso) ha macchine NT.
Vedi quando parli di workstation si preferisce NT perchè è più facile per
l'utente. Per le macchine in cui solo i "tecnici" devono metterci mano ti
assicuro che non è così.... E come dire che per i pc di casa in genere viene
installato win98....


 installato win98....
Non sono cosi` sicuro che NT Workstation sia piu` facile da gestire
di un moderno Linux con l'ultimo Caldera o simile; NT richiederebbe
a mio parere molte piu` skill e attenzioni di system administration di
quante non glie ne vengano normalmente dedicate.  Comunque, se
l'utente e` piu` _familiare_ con l'uso di Windows, per cui preferisce
restare su quella linea, beh, "il cliente ha sempre ragione" (purche`
paghi:-).
Sono d'accordo che il "puro tecnico" tende a preferire Linux, ma ci sono
delle eccezioni, anche "puramente tecniche".  I vari Corba, EJB, ecc,
che su Linux puoi usare per fare programmazione distribuita N-layer
per componenti, non lucidano gli stivali a Com+Mts+Msmq -- e questo
non lo dico solo io, ma supertecnici come Sessions (uno degli
architetti di Corba, gia` guru Unix) e Box (un tempo guru del Mac).
Com e soci, anche se Com+ per vari motivi e` stato un po' una
delusione (prometteva mille, ha mantenuto solo cento; e` gia` ben
piu` del "dieci" che c'era prima, ma che sciocchi quelli di MS a
creare aspettative esagerate -- soprattutto quando la concorrenza
in realta` ha circa "cinque e mezzo"...!-), fanno i cerchi intorno alle
proposte della concorrenza.  E` forse l'unico vero punto tecnico di
solidita` della MS.  Purtroppo (o per fortuna secondo i punti di vista)
per l'e-commerce si tratta in effetti di infrastrutture *cruciali*...
Alex

 richieste cosi`!!!-)
Questa volta hai capito proprio male. A me delle librerie a
corredo interessa il giusto (cioe' niente). Faccio sempre in tempo
ad acquistare delle librerie di terze parti se contengono delle
funzionalita' a me utili (vedi le Tools++ della RogueWave o le Qt).
Infatti se in Python posso utilizzare una libreria per le 
regular expression, posso fare altrettanto in C++ utilizzando
le RegEx di John Maddock.
Bene ribaltiamo la domanda nella seguente forma, TU, nella 
azienda ove lavori, useresti Python? 
Fausto

 azienda ove lavori, useresti Python?
Certo che lo uso.  Tutti gli script di gestione che avevo fatto
in Perl li sto gradualmente migrando a Python.  Gli script di
rete del nostro sistema e-commerce gia` lo usano (il nostro
specialista "web programmer" e` proprio quello che il Python
me l'ha fatto conoscere).  Le applicazioni che noi sviluppiamo
e vendiamo in tutto il mondo (per la progettazione meccanica
tri-dimensionale -- 
http://www.think3.com
) espongono un
modello ad oggetti COM, ed ospitano linguaggi di scripting del
tutto generali purche` compliant ad Active Scripting, e Python
ovviamente lo e`, quindi puo` essere usato per qualsiasi
compito di scripting (il bello dell'Active Scripting naturalmente
e` che vi e` totale intercambiabilita`, per cui se l'utente e`
invece un patito di Perl, VB, Rexx, o checche` d'altro, nessuno
gli vieta di continuare a usare quel che preferisce).
Alex

 funzionalita' a me utili (vedi le Tools++ della RogueWave o le Qt).
Ma se non conosci bene quelle standard (e non è facile in quanto sono
molto ricche) come puoi sapere se una certa funzionalità già la hai a
disposizione o meno? Mica acquisterai le librerie di terze parti anche
per i contenitori e/o gli algoritmi standard, no?
EMG


Scusa se mi intrometto, ma mi interessa sapere
se tu conosci un qualche metodo che misuri
*in modo quantitativo* il livello di
"chiarezza e linearita`" di un certo codice.
Voglio dire a me interessa, se esiste, un metodo
che consenta di dire in modo oggettivo
ad esempio: "il livello
di 'chiarezza e linearita`' del codice X e`
7, mentre il livello di  'chiarezza e linearita`'
del codice Y e` 4".
Lo chiedo perche' a me e` capitato di recente di utilizzare
un server WEB (Zope) che rende disponibile un suo "dialetto"
per la programmazione Dynamic HTML. Questo dialetto
e` Python-oriented (credo che tutto il server sia scritto in
Python), ma stavo quasi pensando che se mi costrivo
una libreria in C++ comprendente varie cose, tra cui
le cgi necessarie per l'accesso al database avrei
fatto prima che continuare a usare il suddetto
dialetto.
Da quanto dici sembra proprio che non sia cosi`.
Forse devo studiarmi meglio il Python,
Marco Guidi

le RegEx di John Maddock.
Se e` per questo anche in C++ posso utilizzare una libreria per
l'unificazione ed implementarmi le funzionalita` di prolog...
ma probabilmente e` piu` conveniente utilizzare direttamente
prolog interfacciandolo col C/C++ e facendo fare a ciascuno
dei due le cose in cui ognuno eccelle. Il fatto che un linguaggio
ti permetta di risolvere qualunque problema non significa che sia
sempre la scelta migliore.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

 "chiarezza e linearita`" di un certo codice.
Si`, ed e` costosissimo.  E` lo stesso metodo che
si usa per misurare, in modo altrettanto quantitativo,
il livello di "penetrazione di un messaggio" nel mondo
del marketing, eccetera.  E` il metodo del "sample
group", e lo troverai illustrato (comprese le relative
tecniche statistiche) sui manuali avanzati di materie
relative alla psicometria.
Poiche` il costo di questo approccio e` cosi` enorme
(in quanto richiede molteplici gruppi, molto numerosi,
molto vari, seguiti da un grande numero di studiosi
specialisti, eccetera), e` praticamente in disuso anche
nel mondo del marketing (sostituito da tecniche piu`
o meno alternative, e comunque molto meno costose,
come il "focus group" -- che pero` spesso e volentieri
producono risultati del tutto inaffidabili).
Fra i pochi linguaggi sottoposti a questi studi nonostante
il costo ci sono Python (i costi sono finanziati come parte
del progetto "CP4E", ovvero "Computer Programming
For Everyone", del governo USA) e il suo "predecessore"
ABC ("predecessore" solo nel senso che fu il linguaggio
di cui Guido van Rossum si occupo` prima di inventare il
Python), che fu sottoposto a uno studio congiunto da
parte di varie facolta` dell'Universita` di Amsterdam (non
e` certo la facolta` di informatica che si intende di queste
cose...).  Trovi la bibliografia degli studi in questione a
partire dal sito 
www.python.org
 (non sono in rete, ma i
vari journal di psicometria ecc su cui sono stati pubblicati
puoi sicuramente procurarteli).
Riassumendo, gli studi preliminari del CP4E indicano
esattamente due punti deboli del linguaggio in termini
di "immediatezza intuitiva" per l'utente che NON ha mai
programmato un computer in vita sua...:
1. e` case-sensitive.  Questa scelta, cosi` popolare
    nei linguaggi sviluppati negli ultimi 30 anni o poco
    meno, pare problematica rispetto all'"intuizione"
    del non-(ancora)-programmatore.
2. la divisione intera (indicata con il simbolo /, e questo
    non e` un problema) *tronca* (per ottenere come
    risultato un altro intero) invece di produrre un numero
    frazionario -- anche questa e` una scelta comune a
    molti linguaggi, ma lascia perplesso "l'uomo medio".
E` interessante notare come, delle infinite scelte piccole
e grandi -- lessicali, sintattiche, semantiche -- di cui si
compone un linguaggio, solo queste due sono risultate
problematiche.  (E` anche interessante, benche` un
dettaglio, notare che Wirth nel suo Pascal prese invece
le decisioni che paiono da questo studio "giuste", cioe`
di rendere il linguaggio case-insensitive E di usare un
operatore speciale, la parola-chiave DIV, per la divisione
intera con troncamento, riservando / alla divisione che
produce come risultato un numero reale; naturalmente,
molte altre scelte del Pascal, come l'uso obbligatorio di
separatori punti-e-virgola e le parole chiave BEGIN/END,
sono invece implicitamente condannate da questo stesso
studio, visto che valida le scelte opposte del Python).
Chiaramente, gli studi proseguiranno (visto che i fondi
non gli mancano, e non essendo un'azienda privata non
hanno particolare incentivo a risparmiarli:-).
Naturalmente, e` anche questione di "target audience".
Ad esempio, la "target audience" di questo studio e`
anglofona.  Per un pubblico NON anglofono, l'uso di
parole-chiave come "if", "while", "class", eccetera, che
a quello di lingua inglese "va giu` liscio", potrebbe
invece essere un problema.  Per un pubblico abituato
a scrivere da destra a sinistra, potrebbe essere un
problema che Python, come le lingue occidentali, si
scriva da sinistra a destra.  E cosi` via.
E` anche importante notare che il target qui e` il
pubblico dei NON-programmatori.  Se si mirasse
invece a chi e` gia` abituato a programmare, e in
special modo se si mirasse a chi e` abituato a UN
solo linguaggio, i risultati senza dubbio potrebbero
essere diversi.  Per fare solo un esempio, chi gia`
conoscesse il C++ difficilmente trovera` problemi
nel case-sensitive o nel / che tronca, perche` vi si
e` gia` abituato; al contrario, essendo abituato
a scelte diverse da quelle Python su altri aspetti,
puo` darsi che trovi "strano" quello che, a chi parte
_senza_ conoscere gia` un linguaggio, sembra la
cosa piu` normale e intuitiva del mondo.
Per fare un esempio, un programmatore C++,
vedendo:
    if 3.2 < x < 4.6:
        euno(x)
        edue(x)
potrebbe restare sconvolto da vari dettagli, come
i due confronti cui x e` sottoposta, il fatto che la
istruzione "if" non necessita di parentesi, il fatto
che l'annidamento delle istruzioni seguenti fa si`
che entrambe dipendano dalla condizione (senza
bisogno di marcatori come le graffe), eccetera.
Per chi non ha gia` aspettative formate da un
linguaggio precedente, questa sintassi e questa
semantica, cosi` dicono gli studi sunnominati,
sono piu` chiare e limpide che non, diciamo...:
    if(3.2<x && x<4.6) {
        euno(x);
        edue(x);
    }
dove l'annidamento e` una pura convenzione,
le parentesi ci vogliono tutte, la x va ripetuta
per poterla confrontare due volte, i punti e
virgola sono obbligatori, le graffe pure... per
non dire di quell'"&&"!-)
Oltre al modo in cui le nostre stesse esperienze
precedenti ci hanno plasmato (e qui, il fatto di
conoscere una ventina di linguaggi diversi e che
provengano da matrici le piu` varie, puo` essere
il modo migliore per evitare pregiudizi legati alle
scelte fatte da un linguaggio in particolare), c'e`
un altro fattore che rende assai relativa l'utilita`
_per l'individuo_ delle misurazioni quantitative
cui prima ci riferivamo: sono, naturalmente, delle
misurazioni di natura *statistica*, che quantificano
gli impatti psicologici di un qualcosa *su di una
ampia gamma di persone*.
Questi possono essere dei *predittori* di un certo
valore (per cercare di indovinare a priori come
reagira` un altro, dato individuo del target), ma
nulla piu`.
In altri termini: se studi scientificamente rigorosi
dovessero dimostrare che il 73.2% dei maschi
italiani quarantenni laureati apprezza il sapore
dei broccoli, a me, per quanto ben parte del target
teste` descritto, ***che cosa mai importa***???
Se dovessi produrre o vendere verdure, certo, un
simile risultato mi sarebbe prezioso.  Ma, vedendo
me stesso come _consumatore_ di questi prodotti,
visto che *A ME PERSONALMENTE* i broccoli NON
piacciono, che la stragrande maggioranza dei miei
pari li adori *non mi fa ne` caldo ne` freddo*, ti
pare?
Il mondo e` bello perche` e` vario, e le persone,
come individui, differiscono l'uno dall'altro molto
di piu` di quanto non differiscano le "medie" dei
gruppi.  E questo e` particolarmente vero quando
si tratta di un'attivita` _creativa_, come, per
quanto si tenti di "sistematizzarla", resta e DEVE
restare lo sviluppo di software.
Alex

 
Di questo ne siamo tutti coscienti altrimenti faremmo altri mestieri.
OK se per te la libreria e' fondamentale come termine di paragone, 
potremmo benissimo  immaginare che tra un mese possa essere resa 
pubblica una versione che del C++, che con molta fantasia si chiami 
C+++, il quale supporta le stesse identiche librerie del Python.
Perche' dovrei scegliere Python?
Fausto

 per i contenitori e/o gli algoritmi standard, no?
Lo standard non supporta ne la persistenza degli oggetti, ne la gestione
dei BTREE su file, quindi uso Tools++. Lo standard non mi apre una
finestra su ambienti diversi con una riga di codice, quindi uso Qt.
Fausto

 
Ok per lo script, ma per il core non ho letto che usi Python.
La ragione?
Fausto

 Perche' dovrei scegliere Python?
Non puoi basare i tuoi giudizi su cose ipotetiche ma solo su ciň che
esiste attualmente, non ti pare?
EMG

 finestra su ambienti diversi con una riga di codice, quindi uso Qt.
Appunto. Questo puoi saperlo solo dopo aver visto cosa contiene la
libreria standard.
EMG

 La ragione?
Prestazioni!  Python e` fatto per "tenere assieme", come
linguaggio di alto livello (ovvero "di scripting" che dir si
voglia) componenti di basso livello scritti in altri linguaggi
piu` orientati alle prestazioni e meno alla produttivita` del
programmatore (Fortran, C++, Assembler, eccetera).
Alex

Perche' dovrei scegliere Python?
Per almeno 2 motivi:
a) quella libreria non sarebbe standard, il che significa che se hai
     esigenze di portabilita` tra piattaforme differenti potresti avere 
     brutte sorprese.
b) Nonostante la libreria, Python (o chi per esso) potrebbe ancora
     essere superiore sotto tanti aspetti. Ad esempio difficilmente
     riusciresti a trovare una libreria C++ che ti fornisca tutta la 
     potenza e l'espressivita` del prolog (con due righe di prolog
     ad esempio riesci a fare cose che in C++ richiederebbero
     molto piu` tempo e fatica) o, altro esempio, difficilmente
     in C++ riusciresti a fare programmazione funzionale come in
     LISP...
Come e` gia stato piu` volte sottolineato da me ed altri, il linguaggio
nudo e crudo non e` un metro sufficiente per effettuare una scelta, puoi
avere una idea di principio circa le capacita` e l'orientamento del
linguaggio, ma devi comunque considerare che la presenza
di una libreria STANDARD (che in quanto tale e` sempre disponibile
e non cambia da piattaforma a piattaforma) puo` eliminare totalmente
lacune presenti a livello di keyword (ad esempio gli stream del C++ vs
le read e write del pascal). Naturalmente una libreria anche se standard
puo` non essere la chiave di svolta, ma non puoi escluderla a priori
altrimenti il C ed il C++ non avrebbero mai raggiunto la popolarita`
di cui hanno goduto o godono tutt'ora.


finestra su ambienti diversi con una riga di codice, quindi uso Qt.
Ma in un altro linguaggio potrebbe essere cosi` e i tuoi requisiti
tali da determinare l'abbandono del C++ a favore di quell'altro
linguaggio. Cio` capita molto piu` spesso di quanto credi
anche per altri fattori (ad esempio le librerie di terze parti anche se
portabili potrebbero essere molto costose in se o in termini di
ore di lavoro).


 Alex
Sul fatto che DEVE restare sono in disaccordo
piu` che totale,... ma come sopra:
"il mondo e` bello perche' e` vario."
ciao,
Marco Guidi

>installato win98....
Non ho capito a cosa ti riferisci.
Antonio

 dei benefici...
Vi sono branche della "teoria della decisione" che misurano
l'incertezza ottimale per una decisione (considerando sia il
costo di ridurre l'incertezza raccogliendo altre informazioni,
sia il beneficio probabilisticamente atteso da un'incertezza
minore).  Non credo che nessuno le usi _formalmente_
se non in ambiti molto specialistici (margin trading nei mercati
dei future, per esempio, dove modelli computerizzati molto
sofisticati possono anche incorporare teorie del genere; la
maggior parte delle decisioni che un professionista ed un
manager devono prendere continuamente non si prestano
affatto altrettanto bene a modellazioni cosi` rigorose).
Alex

 > affermazioni del genere.
... andrebbe rivista perche' offensiva nei confronti di quei
programmatori
che amano quel linguaggio e scrivono codice "chiaro e lineare".
Come ami ripetere, il mondo e' bello perche' e' vario.
Fausto.

 Come ami ripetere, il mondo e' bello perche' e' vario.
Certamente, ma cio` non impedisce di cogliere e rilevare
le contraddizioni fra due affermazioni, o fra una affermazione
ed un comportamento.
Alex

 semplice Fortran vettorizzato e parallelo.
Ma non hai affermato in una mail precedente che non lo usate
nel core della vostra applicazione per problemi di prestazioni?
Fausto

>Mi sembra che per usare i thread di Linux occorra compilare i moduli
insieme al web server. La cosa non e' sempre fattibile oltre >che
deprecabile.
Però è anche vero che nei sistemi Unix è normale dover ricompilare un
programma prima di usarlo, kernel compreso.
E' uno dei motivi per cui di solito Unix è più efficiente di altri sistemi,
ma se non gliene si dà la possibilità...
--
Alessandro Monti

>ma se non gliene si dà la possibilità...
Quindi ad esempio io faccio un'applicazione web per un cliente, vado dal cliente, ricompilo il web con i miedi moduli e me ne vado!
Roba da pazzi!
Antonio

Non ho capito a cosa ti riferisci.
Che una semplice persona che deve lavorare su una workstation a malapena ha
le conoscenze per far avviare il programma che deve usare, figuramoci usare
linux....


>linux....
Sono d'accordo ma non capisco cosa c'entri in questa discussione.
Antonio

Roba da pazzi!
Non hai capito, il kernel supporta tantissime cose, però per evitare di
sovraccaricare il kernel di cose inutili (tipo supporto per hardware che non
si ha sulla macchina) lo si tiene più scarico.
Se poi qualcuno ha delle necessità che fa? prende e aggiunge al kernel
quello che gli serve.
Una applicazione che necessiti l'inserimento di moduli (e ti assicuro che
sono rare) deve essere rilasciata a chi la aquista completa di sorgente...
Questo perchè sia il modulo che l'applicazione deve essere compilata.
Per cui quando tu vai dal cliente, fai l'istallazione e gli lasci tutto...
La maggiorparte dei programmi in linux sono distribuiti cosi.
E a dire la verità pochissimi sono a pagamento.


>E a dire la verità pochissimi sono a pagamento.
Anche per Windows ci sono tonnellate di programmi gratuiti.
Antonio

 nel core della vostra applicazione per problemi di prestazioni?
Certo che l'ho affermato, la quote e` ancora qui sopra.  Che il
nostro kernel di geometria computazionale 3D (che immagino sia
quello che intendi con "core" -- a meno che tu non voglia invece
parlare di "core 'ngrato"...?) sia in C++ molto ottimizzato, viene
da ovvie esigenze di prestazioni; similmente, nelle applicazioni di
supercomputing cui accennavo, vi sono altrettanto ovvi vincoli su
tutti i kernel computazionali (BLAS e aggiunte al BLAS in qualsiasi
programma tratti enormi matrici, simulazione ab initio delle reazioni
in qualsiasi programma di chimica computazionale, ecc ecc) -- si
usa il Fortran, l'assembler, o il C/C++, a seconda dei casi.
Cio` non significa affatto "tenersi il piu' lontano possibile da
Python", significa fornire esattamente quei componenti che
si potranno poi _pilotare_ nel modo piu` fruttuoso.  Come ho
gia` ripetutamente spiegato, la nostra strategia di componenti
si impernia sul Component Object Model, che personalmente
giudico essere l'unico segmento di tecnologia *veramente
valida* di matrice Microsoft (e non sono l'unico a pensarla
cosi`, cfr ad esempio i testi di Roger Sessions e Don Box); fra
i vantaggi del COM vi e` l'indipendenza dal linguaggio, per cui
sia l'implementazione di un componente, sia il codice-cliente
che pilota/utilizza il componente stesso, possono essere scritti
in linguaggi qualsiasi (ad esempio, e` possibile _prototipare_ un
componente in un linguaggio di elevata produttivita`, arrivando
a definirne le interfacce con precisione e rigore e permettendo
lo sviluppo del codice-cliente, poi cambiare l'_implementazione_
del componente stesso, se il suo uso diventa diffuso ovvero se
avviene in punti del codice che costituiscono "colli di bottiglia"
per le prestazioni di qualche operazione importante, ottenendo
le ottimizzazioni desiderate).
Segue su di un post separato "Strutturare le applicazioni" (non
riesco a postare questo in modo completo, penso per ragioni
di dimensioni... [?]).
Alex

Roba da pazzi!
Ma come, è UNIX. (no, è Linux, ma fa lo stesso).
Purtroppo è così, sotto Linux le prestazioni si pagano con la
ricompilazione. In Windows si pagano con i crash!
Ovvero: il modello di Unix è che i programmi e le librerie devono essere sì
veloci, ma sempre *sicuri*, nel senso che un programma o una libreria (tipo
le DLL) scritti male non devono crashare il sistema, ma solo esse stesse.
Sotto windows, invece, usare le DLL è facile e veloce. Non si perde in
prestazioni usando le DLL (o solo poco) rispetto al "monoblocco", ma in
compenso una brutta applicazione o una DLL possono fermare l'intero sistema.
Unix (e Linux) hanno deciso che la sicurezza è più importante delle
prestazioni: se le vuoi, devi ricompilare e avere il monoblocco. Se vuoi la
modularità, e di conseguenza non avere la necessità di ricompilare, sei
lento.
La realtà, poi, come sempre sta un po' nel mezzo: Linux talvolta crasha, e
Windows (soprattutto NT) ha una ottima stabilità. Posso dire però per
esperienza diretta che entrambi i SO, rispettando la loro filosofia, sono
entrambi molto veloci, ma Linux ha una maggiore stabilità.
Ho avuto per 2 anni alle mie spalle 2 server: uno Intranet-internet Linux,
un SQL-server NT. Indovinate quale ha avuto più bisogno di amorevoli cure?
Ad esempio, dopo un blackout improvviso (un disastro, si sono bruciati pure
i gruppi di continuità... errore umano), Linux si è prontamente ripreso,
mentre NT è defunto. Problema dell'HW, probabilmente, ma vedere un PC che si
railzava dopo la caduta e l'altro restare immobile a terra fatalmente ferito
è stato molto triste...
Ma mi sono lasciato prendere la mano: non ho motivo di preferire uno o
l'altro sistema, dato che entrambi sono comunque ottimi. Mi dispiace però
che uno dei 2 non sia valutato per quello che è e usato come si deve. Usare
Linux senza mai ricompilare niente e aspettarsi le prestazioni di un
missile, è come far girare un programma Windows con un emulatore su Mac e
poi dire: "E' lento..."
--
Alessandro Monti

 
Purtroppo COM non e' anche multipiattaforma... Un'architettura simile
ma multipiattaforma (e molto diffusa) e' CORBA, ma in un altro post
hai affermato che e' ritenuta essere inferiore a COM+: solo per
curiosita', potresti illuminarmi sui motivi di tale giudizio?
Saluti,
-- 
Diego    | Per le repliche elimina dal mio indirizzo le 
Dainese  | `x' e inverti le due parole intorno alla `@'

 Anche per Windows ci sono tonnellate di programmi gratuiti.
Ma molti non ti permettono di fare ciò che puoi fare con linux.
Volendo io potrei farmi un web server, con ftp server, con server news e il
tutto gratuitamente e con funzioni e prestazioni simili a quelle di un vero
server. Prova a fare la stessa cosa con le stesse funzioni con NT e vedrai
che dovrai sborsare testoni in software.


 andava con i client Windows 95.
E la versione della Caldera precedente secondo te è recente?
Invece di usare la comunissima Redhat o le tante altre più aggiornate.....
Pensa io ho il kernel 2.2.12 di novembre, a breve uscira quello nuovo col
supporto USB e quello per il multiprocessore ottimizzato, più altre cose che
erano in via sperimentale.
Gli unici cambiamenti di kernel in corsa di windows sono per rattoppare
buchi sulla sicurezza


 curiosita', potresti illuminarmi sui motivi di tale giudizio?
Roger Sessions, uno degli architetti di Corba e attualmente
grande patito di COM, spiega dettagliatamente le sue ragioni
sul suo sito e sulla sua newsletter (trovi sul sito gli archivi e
puoi abbonarti alla NL in email) dal punto di vista di un patito
dell'elaborazione distribuita. 
http://www.objectwatch.com/
.
Personalmente, non sono un grande patito del distribuito (e`
importante, ma la grande maggioranza di quello che faccio,
almeno per ora, gira su 1 scatola alla volta) e quindi le mie
motivazioni sono diverse (piu` simili a quelle di Don Box, vedi
http://www.develop.com
).  In altri termini, a me per ora non
interessa tanto uno standard per l'elaborazione distribuita ma
uno per la interoperabilita` di componenti; e Corba _non lo
e`_ (neppure davvero _pretende_ di esserlo).  L'unico modo
che ti garantisce di fare interoperare dei "ponenti" Corba
(com-ponenti senza COM, quindi, solo ponenti...:-) e` di
metterli in processi diversi con una connessione simulata di
rete fra loro e IIOP su quella simulazione di rete; l'efficienza
naturalmente va a farsi benedire.
COM, a differenza di Corba, *COMINCIA* con lo specificare
quanto occorre per l'interoperabilita` di componenti entro
un singolo processo (a partire dal layout binario della virtual
table che definisce una interfaccia del componente, e dagli
aspetti di 'navigazione' fra interfacce e di controllo molto
semplice del lifetime del componente); tutto il resto viene
costruito su questa solida specifica.
Vedi ad esempio 
www.mozilla.org
: non e` certo su Corba
che la versione open-source di Netscape sta basando la
propria strutturazione interna in termini di componenti,
bensi` su di una fedele imitazione del COM, chiamata non
a caso XCOM (purtroppo con molte limitazioni rispetto al
COM vero, ad esempio gli aspetti multi-linguaggio non
possono non soffrire dal fatto che COM e` in giro da
quasi 10 anni quindi i vari compilatori e interpreti ormai
lo supportano, mentre XCOM non lo supporta nessuno
quindi e` usabile solo da C/C++ o assembler, quando cioe`
hai il controllo preciso sui layout &c; inoltre, a XCOM manca
naturalmente tutta la ricca infrastruttura di servizi e di
interfacce standard e loro implementazioni che il COM
invece gia` fornisce; infine, e piu` grave, XCOM non da`
nessun equivalente di "Automation" per supportare l'uso
da parte di linguaggi puramente interpretativi).
Alex

 che dovrai sborsare testoni in software.
Guarda che Xitami, Apache, Medusa, ..., sono altrettanto gratis per
NT quanto per Linux o qualsiasi altro Unix.  Sono gli _stessi_ programmi.
Sospetto che le prestazioni saranno migliori su Linux (meglio calibrato
per fare da server, mentre NT almeno nella workstation edition ha una
serie di cose per privilegiare l'uso interattivo; e NT Server costa caro)
se pensi a una macchina mono-processore.  Ma non mi pare che come
spesa dal lato NT ci sia altro oltre al semplice sistema operativo.
Alex

>poi dire: "E' lento..."
Ancora una volta devo ripetere che PC professionale (anzi la cugina americana, che mi sembra si chiami PC Labs) ha chiamato i fornitori per ottimizzare al meglio i sistemi.
Antonio

>che dovrai sborsare testoni in software.
Il web server, l'ftp server e il news server fanno parte di NT. Ti e' andata male.
Antonio

>buchi sulla sicurezza
Window 3.1 ha soppiantato il DOS.
Windows 3.11 ha inventato il workgroup, l'OLE, etc.
Windows 95 e' diventato multithreading reale, nomi dei file lunghi, COM, DCOM, Plug And Play, interfaccia utente molto potente, accesso ad Internet molto semplificato.
Windows 98 ha fatto diventare l'interfaccia utente un tutt'uno con Windows: internet explorer, active desktop, outlook, personal web server, etc.
Windows 2000 ha: Active Directory Service, Kerbero per la gestione della sicurezzak, etc.
Fai te.
Antonio

 Il web server, l'ftp server e il news server fanno parte di NT. Ti e'
andata male.
Ho detto gratuitamente....
Quanto paghi invece NT?


 Windows 2000 ha: Active Directory Service, Kerbero per la gestione della
sicurezzak, etc.
Se parli di w2000 parli di NT, che è diverso da win9x...
Non so cosa è stato migliorato però rimane un sistema che non ti da una
certa libertà....
Esistono tanti di quei piccoli mattoncini in linux che tu puoi scegliere
esattamente quello che vuoi, e la cosa bella è che il più delle volte i vari
mattoncini possono interagire tra loro in vari modi...
Non mi accanisco contro MS, ma voglio solo fare capire che non è tutto oro
quello che luccica....


it.comp.os.dibattiti please 

 certa libertà....
In che senso????
Fausto

>quello che luccica....
Come tutto d'altronde.
Antonio

>estetica, ma non come funzionalità...
Praticamente stai dicendo che tutti i bravi sviluppatori lavorano in Linux. Tutti gli altri che guardano solo i fronzoli lavorano in Windows. E meno male che non sei prevenuto.
Antonio