Microsoft Update sotto test

Parte la prima fase di beta testing di un nuovo servizio di aggiornamento: sostituirà Windows Update entro l'anno. Il nuovo centro di raccolta e distribuzione delle patch supporterà anche Office


Redmond (USA) – In questi giorni è cominciata la fase di beta testing di Microsoft Update (MU), un’evoluzione dell’attuale servizio di aggiornamento Windows Update (WU) che dovrebbe essere completata verso il tardo 2005.

A differenza di WU, che contiene quasi esclusivamente aggiornamenti relativi a Windows ed ai suoi componenti, MU diverrà il punto di raccolta e distribuzione delle patch per i più importanti software di Microsoft , tra cui Office, Exchange e SQL Server. Il servizio sarà accessibile agli utenti di Windows 2000, XP e Server 2003 e si interfaccerà alla funzionalità Aggiornamenti automatici di Windows, che di fatto rappresenta il client di WU alternativo all’accoppiata browser/ActiveX: un client che, come noto, permette di scaricare gli update in modo manuale, automatico e/o programmato.

“Il consolidamento degli aggiornamenti è la naturale estensione della filosofia alla base di Windows Update. Separati meccanismi di aggiornamento per Office e Windows sono per gli utenti scomodi e onerosi”, ha affermato Joe Wilcox, analista senior presso Jupiter Research.

Microsoft ha comunque detto che i siti WU e Office Update rimarranno attivi anche dopo il debutto di MU: questo per andare incontro alle esigenze di specifici clienti.

In una e-mail inviata ai propri beta tester, Microsoft ha spiegato di aver mutato il nome del suo servizio da Windows Update a Microsoft Update per sottolineare l’importanza dell’aggiornamento.

“Questa beta sarà molto più complessa (da testare, NdR) delle precedenti beta di Windows Update”, ha scritto nella lettera Roger Holland, Beta Coordinator di MU. Una complessità rispecchiata dal fatto che per l’occasione il big di Redmond ha chiamato a raccolta ben 25.000 tester, buona parte dei quali ha già partecipato al testing di Windows Update v5 (il cui supporto è stato incluso nel Service Pack 2 per Windows XP).

Al momento anche MU, al pari di WU, può essere utilizzato esclusivamente con Internet Explorer: una limitazione che il crescente successo di Firefox sembra destinato a rendere sempre più vistosa.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Giambo scrive:
    WOW
    Cioe', ma vi rendete conto ?!? IPv6 ? Non IPv4 o IPv5 o magari IPv5.7beta, ma IPv6 !!Cioe' troppo avanti sono questi della maicrosoft ! Non vedo l'ora che arrivi il 2019 per poter usare l'IPv6 (O magari sara' gia' IPv7 o IPXP ) mentre Linux avra' cosa ? IPv2eTreQuarti ?(troll4) :D (linux)==================================Modificato dall'autore il 24/03/2005 11.18.45
    • FDG scrive:
      Re: WOW
      Eccerto, Maicrosoft, il motore dell'innovazione!:D :D :D
    • Anonimo scrive:
      Mah...
      - Scritto da: Giambo
      Cioe', ma vi rendete conto ?!? IPv6 ? Non IPv4 o
      IPv5 o magari IPv5.7beta, ma IPv6 !!
      Cioe' troppo avanti sono questi della maicrosoft
      ! Non vedo l'ora che arrivi il 2019 per poter
      usare l'IPv6 (O magari sara' gia' IPv7 o IPXP )
      mentre Linux avra' cosa ? IPv2eTreQuarti ?

      (troll4) :D (linux)

      ==================================
      Modificato dall'autore il 24/03/2005 11.18.45Ti faccio notare che il supporto al protocollo IPv6 è già installabile su Windows 2000/XP e 2003, quindi nessuna novità... ti faccio anche notare che IPv6 non è un protocollo Microsoft ma è un protocollo standard che dovrebbe andare a sostituire l'attuale IPv4... oltre a questo ti faccio anche notare che il supporto a IPv6 è già presente in moltissimi sistemi operativi (ad esempio OpenBSD... ma penso anche Linux ormai). Linux è dovuto arrivare al kernel 2.6 per non gestire i thread delle varie applicazioni come processi separati... chissà dove potranno arrivare Linux e Windows nel 2019 ;-)
      • Anonimo scrive:
        Re: Mah...

        Ti faccio notare che il supporto al protocollo
        IPv6 è già installabile su Windows 2000/XP e
        2003, quindi nessuna novità...appunto lo hai detto te:NESSUNA NOVITA'solo che microsoft ama vendere aria fritta e gli utonti ci cascano subito :)
      • FDG scrive:
        Re: Mah...
        - Scritto da: Anonimo
        Ti faccio notare che il supporto al protocollo
        IPv6 è già installabile su Windows 2000/XP e
        2003, quindi nessuna novità...E infatti lo usano tutti. Strano, non me ne sono accorto.
        ti faccio anche
        notare che IPv6 non è un protocollo Microsoft ma
        è un protocollo standard...Il problema non è se è standard o meno, ma se Microsoft deciderà di sfruttarlo come si deve oppue preferirà ricorrere ai soliti mezzucci per fare le scarpe agli altri. Certo, dato che i dispositivi che controllano il traffico di rete non sono prodotti da Microsoft, una cosa del genere è meno probabile.
      • Giambo scrive:
        Re: Mah...
        - Scritto da: Anonimo

        Cioe', ma vi rendete conto ?!? IPv6 ? Non IPv4 o

        IPv5 o magari IPv5.7beta, ma IPv6 !!

        Cioe' troppo avanti sono questi della maicrosoft

        ! Non vedo l'ora che arrivi il 2019 per poter

        usare l'IPv6 (O magari sara' gia' IPv7 o IPXP )

        mentre Linux avra' cosa ? IPv2eTreQuarti ?


        Ti faccio notare che il supporto al protocollo
        IPv6 è già installabile su Windows 2000/XP e
        2003, quindi nessuna novità...Hue', prenditela con Jawad Khaki, io commento quel che lui ha detto !
        ti faccio anche
        notare che IPv6 non è un protocollo Microsoft ma
        è un protocollo standard che dovrebbe andare a
        sostituire l'attuale IPv4... oltre a questo ti
        faccio anche notare che il supporto a IPv6 è già
        presente in moltissimi sistemi operativi (ad
        esempio OpenBSD...
        ma penso anche Linux ormai).Ehm ... La mia voleva essere ironia sul fatto che la Microsoft ancora una volta arriva fuori tempo massimo, IPv6 e' supportato da sistemi seri gia' da diversi anni.
        Linux è dovuto arrivare al kernel 2.6 per non
        gestire i thread delle varie applicazioni come
        processi separati...Mah, ce n'era veramente bisogno ?
        chissà dove potranno
        arrivare Linux e Windows nel 2019 ;-)Chissa' se uscira' Longhorn entro quella data :D
        • Anonimo scrive:
          Re: Mah...


          Mah, ce n'era veramente bisogno ?
          se non usi piu' di un processore FORSE no..
          • FDG scrive:
            Re: Mah...
            - Scritto da: Anonimo
            se non usi piu' di un processore FORSE no..Premetto che non mi interesso più di tanto di queste cose. Però non capisco la critica. Che io sappia la contrapposizione è sulle metodologie di sviluppo, tra chi preferisce avere processi separati e chi un unico processo su più thread. Anche perché più processi li distribuisci tranquillamente tra più CPU, meglio ancora se questi non hanno informazioni di stato in comune. Semmai è al contrario, un processore da solo deve fare meno lavoro per passare da un thread ad un altro. Mentre due processori devono mettersi daccordo se eseguono due thread nello stesso contesto, perché le informazioni di stato devono rimanere coerenti.
          • Anonimo scrive:
            Re: Mah...
            - Scritto da: FDG
            - Scritto da: Anonimo


            se non usi piu' di un processore FORSE no..

            Premetto che non mi interesso più di tanto di
            queste cose. Però non capisco la critica. Che io
            sappia la contrapposizione è sulle metodologie di
            sviluppo, tra chi preferisce avere processi
            separati e chi un unico processo su più thread.
            Anche perché più processi li distribuisci
            tranquillamente tra più CPU, meglio ancora se
            questi non hanno informazioni di stato in comune.
            Semmai è al contrario, un processore da solo deve
            fare meno lavoro per passare da un thread ad un
            altro. Mentre due processori devono mettersi
            daccordo se eseguono due thread nello stesso
            contesto, perché le informazioni di stato devono
            rimanere coerenti.Lascia perdere e' il solito che vuole fare il figo sensa avere capito bene di cosa parla! ;-)
          • Anonimo scrive:
            Re: Mah...

            Lascia perdere e' il solito che vuole fare il
            figo sensa avere capito bene di cosa parla! ;-)meno male che ci sei tu ad illuminarci :S
          • Anonimo scrive:
            Re: Mah...
            -
            meno male che ci sei tu ad illuminarci :Sgia' cosa vuoi farci io sono un povero pirla che pensa che con due processori sia piu' efficiente girare a processi separati invece che a thread che ci vuoi fare!Ma in compenso puoi sempre provare a spiegarmi perche' mi sbaglio! ;-)
          • Anonimo scrive:
            Re: Mah...


            meno male che ci sei tu ad illuminarci :S
            gia' cosa vuoi farci io sono un povero pirla che
            pensa che con due processori sia piu' efficiente
            girare a processi separati invece che a thread
            che ci vuoi fare!un esempio banale che può riguardare anche un utente: mentri usi un word processor un thread processa ciò che stai scrivendo mentre un thread in parallelo controlla l'ortografia e la grammatica di ciò che hai scrittoi due thread condividono la memoria e devono solo preoccuparsi di usare primitive "leggere" per sincronizzare l'accesso alla memoria (al documento)se fossero due processi servirebbe come minimo un meccanismo di comunicazione interprocesso (IPC) che è molto più onerosodi esempi simili se ne possono fare a bizzeffe
            Ma in compenso puoi sempre provare a spiegarmi
            perche' mi sbaglio! ;-)perché al posto di fare il sarcastico a sproposito non provi a spiegarmi il tuo punto di vista?
          • Anonimo scrive:
            Re: Mah...
            - Scritto da: Anonimo


            meno male che ci sei tu ad illuminarci :S

            gia' cosa vuoi farci io sono un povero pirla che

            pensa che con due processori sia piu' efficiente

            girare a processi separati invece che a thread

            che ci vuoi fare!

            un esempio banale che può riguardare anche un
            utente: mentri usi un word processor un thread
            processa ciò che stai scrivendo mentre un thread
            in parallelo controlla l'ortografia e la
            grammatica di ciò che hai scritto

            i due thread condividono la memoria e devono solo
            preoccuparsi di usare primitive "leggere" per
            sincronizzare l'accesso alla memoria (al
            documento)

            se fossero due processi servirebbe come minimo un
            meccanismo di comunicazione interprocesso (IPC)
            che è molto più oneroso

            di esempi simili se ne possono fare a bizzeffe


            Ma in compenso puoi sempre provare a spiegarmi

            perche' mi sbaglio! ;-)

            perché al posto di fare il sarcastico a
            sproposito non provi a spiegarmi il tuo punto di
            vista?Forse non ti sei accorto che si parlava di 2 processori i quali a usare la "shared memory" honno un pochino piu' di problemi se non usano meccanismi di sincronizzazione legati a semafori e mutex (esattamente come per i processi).Del resto la shared memory non e' una novita', non e' una trovata particolrmente "furba" e la si usa alla grande anche tra processi diversi (volendo) quindi non si capisce bene il vantaggio del thread! a parte che "fa piu' figo".Il punto reale e' che (in ogni caso) la implementazione corretta dei thread e' piuttosto difficoltosa da rendere efficiente e sopratutto sicura!il problema di condividere memoria tra i "thread" puo' diventare drammatico sa fare andare daccordo coi meccanismi di protezione della memoria stessa!La prova? tra i grandi "condivisori" di memoria ci sono una categoria particolare di applicazioni che si chiamano virus!Sul resto stendo un pietoso velo!
          • Anonimo scrive:
            Re: Mah... [parte 1]

            Forse non ti sei accorto che si parlava di 2
            processori i quali a usare la "shared memory"
            honno un pochino piu' di problemi se non usano
            meccanismi di sincronizzazione legati a semafori
            e mutex (esattamente come per i processi).shared memory significa solo memoria condivisa ed ha differenti signficati in differenti contesti, vediamo di togliere ogni ambiguità partendo dalle basiil problema dell'accesso condiviso alla memoria esiste sia a livello hardware, che a livello di sistema operativoprima di tutto a livello hardware i processori devono contendersi il bus per accedere alla memoria ed utilizzano metodi di arbitraggio dedicati che non hanno nulla a che fare con semafori o mutex che nel contesto della discussione che stiamo facendo sono primitive dei sistemi operativi (o nella peggiore delle ipotesi sono semplici pattern di programmazione)sempre a livello hardware, c'è il problema della coerenza della memoria rispetto alla cache: se nella cache di uno o più processori c'è una copia di una determinata zona di memoria, il sistema deve sincronizzare le copie in cache e la memoriaci sono diversi protocolli per farlo, i processori Intel utilizzano un protocollo detto di "snooping" per garantire la coerenza delle cache e della memoria che, molto brevemente, funziona più o meno così: quando il bus di un processore deve effettuare una transazione con la memoria, chiede a tutti gli altri processori se hanno una copia dei dati in cache nel qual caso il sistema sincronizza tutte le copie in cache e la copia in memoria in modo da poter operare sul dato più recente(ovviamente questo protocollo consuma cicli dei processori e banda del bus con il risultato di un aumento di traffico tra i processori, per questo sono state sviluppate architetture come il chipset Profusion su macchine ad 8 vie che riducono drasticamente il traffico dovuto allo snooping)quindi a livello hardware direi che ci sono alcune problematiche ma nessuna è legata alla nostra discussionea livello di sistema operativo tutto questo scompare, il sistema operativo ha una visione sempre coerente della memoria senza preoccuparsi di come venga arbitrato l'accesso a livello hardwaredal punto di visto del sistema operativo esistono poi i processi, i thread e le fiber (o processi, kernel thread e user thread)ad ogni processo viene assegnato uno spazio di indirizzamento della memoria che può utilizzare a suo piacimento ma che è isolato (punto fondamentale) da quello degli altri processi (che poi questo spazio sia memoria ram o memoria virtuale è irrilevante per il discorso)i processi per comunicare tra loro utilizzano meccanismi di comunicazione interprocesso (IPC) che possono essere semplici scambi di messaggi (anche tra processi su macchine diverse) oppure zone di memoria condivise il cui accesso è arbitrato dal meccanismo di comunicazione interprocesso stessonel caso dei processi il meccanismo di comunicazione interprocesso utilizza primitive quali i segnali, i semafori ed i mutex per arbitrare l'accesso alle risorse che devono essere condivise (tra le quali può figurare anche una zona di memoria)queste primitive devono essere fornite dal kernel perché è l'unico in grado di accedere direttamente allo spazio di indirizzamento di tutti i processi (cioé non posso pensare di implementare un mutex con del codice in un processo per arbitrare l'accesso ad una risorsa in un altro processo)e fare una transizione da user mode a kernel mode costa
          • Anonimo scrive:
            Re: Mah... [parte 2]
            un kernel thread (thread per brevità) non è nient'altro che "un pezzo di programma" (perdona la definizione informale) con un suo stack ed un copia dei registri e del program counter relativa al suo contesto di esecuzionecaratteristica saliente del thread è che opera nel contesto di un processo avendo quindi libero accesso allo spazio di indirizzamento ed alle risorse assegnate a quel processostoricamente con il termine processo ci si è sempre riferiti a quanto detto precedentemente (spazio indirizzamento e risorse) più le caratteristiche del thread (programma, stack, registri e PC), oggi con i sistemi multi-threaded si tende sempre più a considerare il processo come un contenitore logico a cui vengono associati lo spazio di indirizzamento, le risorse ed uno o più thread (con thread principale si intende il primo thread creato all'esecuzione del processo che eventualmente può creare gli altri thread)più thread che condividono lo stesso processo hanno libero accesso alla memoria assegnata al processo stesso (questo non è vero tra processi differenti!) e possono quindi utilizzare primitive meno onerose per arbitrarne l'accesso quali interlocking, critical sections e spinlocksqueste primitive sono meno onerose perche' sono implementate in user modela differenza in termini di prestazioni tra questi metodi di arbitraggio è uno dei punti fondamentaliin ogni caso thread di processi diversi possono comunicare tra loro tramite IPC e possono arbitrare l'accesso alle risorse tramite le primitive offerte dal kernella messa in esecuzione dei thread sulle cpu è governata dallo scheduler del sistema operativo che opera in kernel mode ed è un'operazione (detta di context switching) che consuma parecchi cicliin alcuni sistemi operativi effettuare il context switching tra thread dello stesso processo è significativamente meno oneroso che effettuarlo tra thread di processi diversi, con altri sistemi operativi la differenza è meno marcatain ogni caso questo è un altro punto fondamentale per quanto riguarda le prestazionioltre al processo ed al kernel thread c'è anche lo user thread (fiber per brevità)una fiber è "un pezzo di programma" che opera nel contesto di un kernel thread (quindi in ultima istanza nel contesto di un processo o thread primario) e ne condivide le risorsepiù fiber possono operare nel contesto dello stesso thread e in un processo ci possono essere più thread ognuno con le sue fiberdato che fiber e thread condividono tutti lo stesso spazio processo, possono avvalersi anche le fiber delle primitive di sincronizzazione leggerela messa in esecuzione di una fiber non viene gestita tramite lo schedulatore in kernel mode del sistema operativo, ma tramite uno schedulatore implementato in user mode dallo stesso processo che ospita i thread che a loro volta ospitano le fiber (come minimo il thread primario ed una o più fiber)l'operazione di context switch dei thread viene sempre fatta dallo schedulatore in modalità kernel, ed ha un certo costo, quella delle fiber essendo in user mode ha un costo minorele fiber devono volontariamente rilasciare l'uso del processore ad un'altra fiber (modello cooperativo) mentre i thread vengono interrotti dal sistema operativo (modello preemptive) in base all'algoritmo dello schedulatoreil pro delle fiber, oltre al costo minore di context switching, è quello di poter implementare un algoritmo di schedulazione più efficiente sia per particolari esigenze, che per sfruttare al meglio il tempo allocato al thread che le ospitail contro è che un la fiber potrebbe non rilasciare mai il processore bloccando di fatto la coda dello schedulatore (user mode) del thread a cui appartienedetto tutto questo torniamo a quanto affermi:
            Forse non ti sei accorto che si parlava di 2
            processori i quali a usare la "shared memory"
            honno un pochino piu' di problemi se non usano
            meccanismi di sincronizzazione legati a semafori
            e mutex (esattamente come per i processi).i meccanismi di sincronizzazione di un'area di memoria condivisa non dipendono in alcun modo dal numero di processori, semplicemente dal fatto che la condivisione avvenga tra thread dello stesso processo o tra thread di processi differentia livello hardware esulano dal contesto della nostra discussione perché la coerenza viene mantenuta a meno del sistema operativo e dalla sua architettura single o multi threaded(tra l'altro ci sarebbe da spendere anche due parole per la prossimità di zone di memoria usate per le variabili e le strategie per far si che finiscano nelle cache lines)
            Del resto la shared memory non e' una novita',
            non e' una trovata particolrmente "furba" e la si
            usa alla grande anche tra processi diversipagando lo scotto della comunicazione interprocesso che costa di più della condivisione tra thread dello stesso processoma, ovviamente, tutto dipende dal tipo di applicazione
            (volendo) quindi non si capisce bene il vantaggio
            del thread!che puoi usare delle primitive più leggere per la sincronizzazioneche costa meno il context switchingma il punto fondamentale è dove e come usarlouna soluzione può essere fatta da diversi moduli e non è detto che sia sensato fare un singolo processo con tanti thread quanti sono i moduli, come non è detto che sia sensato fare tanti processi quanti sono i moduliil punto è capire l'interdipendenza tra i vari moduli ed i requisiti di condivisione delle risorse da parte dei vari modulila soluzione potrebbe essere realizzata mappando i moduli in più processi alcuni dei quali con un singolo thread, alcuni con più thread ed infine alcuni con più fibers per alcuni threadun ottimo esempio è un rdbms: processi differenti per servizi integrati tra loro (es. l'engine, full-text, data mining, olap) e più thread per i processi (es. nell'engine un pool di thread serve le connessioni, un thread si occupa dei checkpoint, uno di svecchiare la cache dei dati ecc. ecc.)per contro c'é tutta una classe di applicazioni che si prestano meglio ad essere suddivise in tante unità dello stesso processo da distribuire su cluster di elaboratori
          • Anonimo scrive:
            Re: Mah... [parte 3]

            a parte che "fa piu' figo".queste affermazioni non hanno nessuna ragione di esistere in una disciplina come l'informatica :-) non penserai che l'architettura multi-threading sia stata adottata da tutti i moderni sistemi operativi perché fa figo spero
            Il punto reale e' che (in ogni caso) la
            implementazione corretta dei thread e' piuttosto
            difficoltosa da rendere efficiente e sopratutto
            sicura!in parte è vero in parte noci sono sicuramente delle difficoltà oggettive nel gestire l'accesso concorrente alle risorse e si rischiano deadlock e quant'altro, ma il problema non è dato dall'uso dei thread al posto dei processi (che comunque sono un singolo thread), è un problema intrinseco della soluzione che stai realizzando: se devi sincronizzare l'accesso lo devi fare comunqueè poi vero che spesso molti non capiscono esattamente quando lo strumento è efficace e quando non lo èil caso classico è quello della singola interfaccia grafica: inutile usare più thread per gestirla, complicheresti le cose per niente, meglio avere un singolo gestore degli eventi gestito da un singolo thread, ma ciò non toglie che l'applicazione possa fare uso di altri thread per altre operazionicome nell'esempio del correttore in background di un word processor, posso usare un thread per l'interfaccia ed uno per il correttorese sto usando il word processor su una macchina con due processori avrò un beneficio, se lo sto usando su una macchina con un solo processore apparentemente le prestazioni dovrebbero degradare per via del context switching, ma in realtà non accade perché se faccio le cose bene (e se l'algoritmo di schedulazione del kernel è fatto bene) il thread in background ha una priorità diversa e mentre continuo a scrivere viene schedulato poche volteperò appena stacco le dita per bermi un sorso d'acqua stai tranquillo che quello inizia ad essere schedulato più frequentemente finché non riprendo a scrivereun'altro esempio è il browser
            il problema di condividere memoria tra i "thread"
            puo' diventare drammatico sa fare andare daccordo
            coi meccanismi di protezione della memoria
            stessa!non capisco cosa intendi, i thread accedono liberamente solo alla memoria del proprio processo, tra processi distinti non lo possono fare liberamente, anzi per farlo possono anche esserci delle politiche di sicurezza da rispettare
            La prova? tra i grandi "condivisori" di memoria
            ci sono una categoria particolare di applicazioni
            che si chiamano virus!i virus non c'entrano nulla con il fatto che le applicazioni siano multi-threaded tanto più che si replicano proprio di processo in processo e non di thread in thread
            Sul resto stendo un pietoso velo!questo è quello che ho studiato io a riguardo su vari libri, con tutte le riserve dovute al dover condensare un argomento così vasto in un post e ad eventuali inesattezzesecondo me dovresti prenderti la briga di cercare un pò di informazioni sulle architetture dei sistemi operativi, ne trovi moltissime sia in Internet che in ottimi libri, è un argomento estremamente interessanteanche un pò meno di sarcarmo non sarebbe male ;-)
          • Anonimo scrive:
            Re: Mah...
            lol beh certo è facile sostenere quello che si vuole basta dire e non dire....
            Anche perché più processi li distribuisci
            tranquillamente tra più CPU, meglio ancora se
            questi non hanno informazioni di stato in comune.altamente improbabile che non abbiamo informazioni di stato in comune, ma possibilese però ci sono queste informazioni di stato è bene ricordare che i thread condividono lo stesso address space e possono comunicare con mezzi molto efficienti come la memoria condivisa ed utilizzare primitive come gli spinlock per tentare l'accesso ad una risorsa prima di mettersi in attesa tramite altri metodi che implicano il rilascio del processore (es. semafori e mutex)viceversa un processo deve usare dei meccanismi di comunicazione interprocesso che sono più onerosi
            Semmai è al contrario, un processore da solo deve
            fare meno lavoro per passare da un thread ad un
            altro.ehm... deve fare meno lavoro rispetto a cosa? rispetto al lavoro che dovrebbe fare per passare da un processo all'altro? e perché mai?
            Mentre due processori devono mettersi
            daccordo se eseguono due thread nello stesso
            contesto, perché le informazioni di stato devono
            rimanere coerenti.eheheheh ma non avevi detto che "meglio ancora se questi non hanno informazioni di stato in comune."?se ci sono queste informazioni da condividere, allora i thread offrono meccanismi per condividerle più efficienti, se non ci sono allora non si capisce neppure a cosa dovrebbero servirti questi benedetti thread
          • Anonimo scrive:
            Re: Mah... 2

            se ci sono queste informazioni da condividere,
            allora i thread offrono meccanismi per
            condividerle più efficienti, se non ci sono
            allora non si capisce neppure a cosa dovrebbero
            servirti questi benedetti threadSono quello che si faceva figo con i thread... ;) i thread servono principalmente per gestire più operazioni "contemporaneamente" (anche se qui è tutto da vedere, perchè in realtà sui sistemi ad 1 CPU la "contemporaneità" è solo emulata dal sistema operativo). Esempio... il mio programma ha un'interfaccia grafica e fa il caffè. Se non utilizzo il multithreading, mentre fa il caffè l'interfaccia grafica rimane bloccata poichè le due operazioni girano all'interno di un unico thread e quando viene eseguita una cosa l'altra rimane "ferma" (quante applicazioni avete visto che mentre eseguono qualche operazione freezano la GUI? Troppe...). Questo è solo un esempio... prendete Apache (il webserver) ad esempio, come fa a soddisfare le richieste contemporanee di più utenti? Utilizza più thread...Gestire i vari thread come processi separati (come faceva Linux fino al kernel 2.6) porta ad un metodo non efficiente di gestione delle risorse (tant'è che con la versione 2.6 finalmente si sono adeguati). That's all folks.
  • Anonimo scrive:
    nap ==
    palladium
    A cos'altro pensate che serva una simile funzionalita`...Altro che antivirus, la prima applicazione sara` che i sistemi non aggiornati alle ultime versioni di media player (con le ultime caratteristiche di DRM aka gli ultimi divieti), non potranno aprire film/musica/dvd, accedere ai vari servizi di vendita online eccetera.Ma e` solo l'inizio.Si avvicina il giorno in cui i computer "non conformi" non potranno piu` maneggiare informazioni che chi controlla il sistema non vuole siano maneggiate. Il giorno in cui la rete internet perdera` ogni reale liberta`, perche` la rete e` fatta dai computer e i computer saranno quasi tutti sotto controllo, soggetti a palladium, NGSCB, TCPA o come lo si voglia chiamare. Il giorno in cui eventualmente un computer non conforme al sistema non potra` affatto entrare in internet, con tanti saluti al nuovo mezzo democratico eccetera.
    • Anonimo scrive:
      Re: accesso alle impostazioni di nap
      - Scritto da: Anonimo
      A cos'altro pensate che serva una simile
      funzionalita`...

      Altro che antivirus, la prima applicazione sara`
      che i sistemi non aggiornati alle ultime versioni
      di media player (con le ultime caratteristiche di
      DRM aka gli ultimi divieti), non potranno aprire
      film/musica/dvd, accedere ai vari servizi di
      vendita online eccetera.
      Ma e` solo l'inizio.Bisogna vedere se le impostazioni del NAP sono accessibili all'utilizzatore del compueter o solo alla MS. Nel primo caso non sis tratta di Palladium, nel secondo caso sì.
      • awerellwv scrive:
        Re: accesso alle impostazioni di nap
        - Scritto da: Anonimo

        Bisogna vedere se le impostazioni del NAP sono
        accessibili all'utilizzatore del compueter o solo
        alla MS. Nel primo caso non sis tratta di
        Palladium, nel secondo caso sì.Credo che lasceranno la scelta agli amministratori di rete... altrimenti la rivoluzione sarebbe immediata.. e i profitti sarebbero nulli... dico questo perche' e' difficile monitorare il contenuto di una rete di grandi dimensioni per andare alla ricerca di media protetti d'autore... immaginate una azienda grossa... e i dipendenti saltuariamente scaricano musica e filmati (la pausa la prendono tutti e una canzone non guasta mai)... bum un giorno passa la finanza e fa un controllo a caso e ti trova con circa 50 filmati (cifra a caso) e fi fa una multa megagalattica e TU amministratore di sistema ti ritrovi la cosa anche in penale... quindi MS in questo caso da l'opportunita' di inserire una sorta di palladium interno all'azienda per evitare spiecevoli soprese... ovvero non fa andare i files non drm per evitare dipendenti "furbi". In fondo su questo e' anche giusto SE e ripeto SE rimane confinato in ambito aziendale dove problematiche simili ci sono veramente... se verra' esteso anche al resto dei client beh... prevedo bancarotta MS in meno di 3 anni...
    • Anonimo scrive:
      Re: nap ==
      palladium
      - Scritto da: Anonimo
      A cos'altro pensate che serva una simile
      funzionalita`...

      Altro che antivirus, la prima applicazione sara`
      che i sistemi non aggiornati alle ultime versioni
      di media player (con le ultime caratteristiche di
      DRM aka gli ultimi divieti), non potranno aprire
      film/musica/dvd, accedere ai vari servizi di
      vendita online eccetera.
      Ma e` solo l'inizio.

      senza contare gli 'sgambetti' di M$ ai player concorrenti (vedi Real), o ai trucchetti tipo questo : http://www.theinquirer.net/?article=22055che renderanno di fatto impossibile l'uso di player alternativi su win...
    • Vurdak scrive:
      Re: nap ==
      palladium
      Il giorno in cui eventualmente un
      computer non conforme al sistema non potra`
      affatto entrare in internet, con tanti saluti al
      nuovo mezzo democratico eccetera.Beh, non può entrare in internet? Allora si crea una nuova, gigantesca intranet..
      • Anonimo scrive:
        Re: nap ==
        palladium
        - Scritto da: Vurdak
        Il giorno in cui eventualmente un

        computer non conforme al sistema non potra`

        affatto entrare in internet, con tanti saluti al

        nuovo mezzo democratico eccetera.

        Beh, non può entrare in internet? Allora si crea
        una nuova, gigantesca intranet..Evviva il paradiso dei kraker cosi' finalmente vi togliete dalle scatole e tutto funzionera' a meraviglia!Non vedo l'ora! :D
  • Anonimo scrive:
    è un brevetto!
    maledizione stanno brevettando internethttp://www.freepatentsonline.com/6101499.html
    • Anonimo scrive:
      Re: è un brevetto!
      - Scritto da: Anonimo
      maledizione stanno brevettando internet

      http://www.freepatentsonline.com/6101499.htmlMah! e se fosse "prior art" ?Mi pare che esista da un pezzetto!...io (in ogni caso) ho nel cassetto un ottimo brevetto!Lo ho chiamato "a metod to avoid the patents damage"" if you live in a country where the software ptents are granted go to another country where software patents are avoided and invest your money in this country":-p
  • Anonimo scrive:
    Giorni fa....
    Alcuni giorni fa sul forum si ironizzava sul fatto che la Mac - che ha brevettato il mouse- avesse finalmente (?) deciso di brandizzare un mouse a due tasti...Non sparerò sulla croce rossa, ma che nel 2005 si annunci che nel 2006 finalmente Windows utilizzerà un sistema che risolverà i problemi di log a reti wifi mi sembra eccezionale!!! Per non parlare del fantastico sistema ipv6... ma wow!!! Penso che prima o poi passerò a Win...
    • Anonimo scrive:
      Re: Giorni fa....
      hihihi
      • FDG scrive:
        Re: Giorni fa....
        Per non parlare di quell'aborto di upnp che tenteranno di riappiopparci.Insomma, potremmo divertirci a trollare con una serie di :D :D :D :D (rotfl)(rotfl)(rotfl)(rotfl)... e altre amenità.Ma invece (idea)http://www.kernelthread.com/software/ams/:O (geek)
  • Anonimo scrive:
    Venghino... venghino...

    "Longhorn offrirà un nuovo stack IPv4/IPv6 integrato - ha continuato Khaki - ottimizzato per le connessioni wireless a bassa velocità e le reti multi-gigabit.Questa frase suona come "Michelin ha lanciato un nuovo tipo di pneumatico, ottimizzato dalle utilitarie da 30cv fino alle gran turismo da 300cv. E'di uno squallore immane.
    Il nuovo stack sarà sufficientemente estensibile per consentire una facile integrazione con i prodotti di terze parti, come firewall, parental control e antivirus.Eh ?Firewall di terze parti già ci sono, antivirus a LIVELLO 3 della pila TCP/IP sono pressocchè inutili ed il Parental control è come "Y2K Compilant": fa figo, aumenta le vendite ma non significa (e/o serve a) una beneamata fava.
    • Anonimo scrive:
      Re: Venghino... venghino...


      Il nuovo stack sarà sufficientemente
      estensibile per consentire una facile
      integrazione con i prodotti di terze parti, come
      firewall, parental control e antivirus.

      Eh ?
      Firewall di terze parti già ci sono, antivirus a
      LIVELLO 3 della pila TCP/IP sono pressocchè
      inutili ed il Parental control è come "Y2K
      Compilant": fa figo, aumenta le vendite ma non
      significa (e/o serve a) una beneamata fava.Si riferiva al fatto che costruire estensioni al nuovo stack di rete sarà più facile, in quanto il sistema di hook, presenti a tutti i livelli, è stato potenziato e semplificato.
  • lorenzaccio scrive:
    Progressi
    Bravi, sono arrivati alla tecnologia del mio vecchio Linux di qualche anno fa, e che uso ancora dato che col un router posso stare collegato indipendentemente dal SO dei PC.
    • FDG scrive:
      Re: Progressi
      - Scritto da: Anonimo
      L'intero elenco di features qui illustrate a
      cominciare da IPV6
      Io lo uso da un pezzo! :-PPer curiostià, e che ci fai?
      • Anonimo scrive:
        Re: Progressi
        - Scritto da: FDG
        - Scritto da: Anonimo


        L'intero elenco di features qui illustrate a

        cominciare da IPV6

        Io lo uso da un pezzo! :-P

        Per curiostià, e che ci fai?Ma non saprei... tu che ci fai con IP?io di norma lo uso come sistema di networking e tu?Ad esempio sulla nostra rete (molto vasta) ci si gestisce perfettamente (non in modo "posticcio" come in ipv4) il QoS.. :-p
        • FDG scrive:
          Re: Progressi
          - Scritto da: Anonimo
          Ma non saprei... tu che ci fai con IP?
          io di norma lo uso come sistema di networking e
          tu?Ecco, sei partito col piede sbagliato. Io t'ho fatto una domanda. Ad esempio, io non posso usare IPv6 per il semplice fatto che... insomma a chi cavolo m'attacco se sono solo io? Devo almeno fare un tunnel su IP perché il mio provider non supporta, almeno pubblicamente, IPv6.
          Ad esempio sulla nostra rete (molto vasta) ci si
          gestisce perfettamente (non in modo "posticcio"
          come in ipv4) il QoS.. :-pEcco, già questo è più interessante.
          • Anonimo scrive:
            Re: Progressi
            - Scritto da: FDG
            - Scritto da: Anonimo


            Ma non saprei... tu che ci fai con IP?

            io di norma lo uso come sistema di networking e

            tu?

            Ecco, sei partito col piede sbagliato. Io t'ho
            fatto una domanda. Ad esempio, io non posso usare
            IPv6 per il semplice fatto che... insomma a chi
            cavolo m'attacco se sono solo io? Devo almeno
            fare un tunnel su IP perché il mio provider non
            supporta, almeno pubblicamente, IPv6.E questo infatti e' uno dei modi di usarlo (tunnel) in questo modo infatti io ho una unica rete indirizzata su IPv6 pure su provider diversi che supportano solo IPv4ti pare poco?


            Ad esempio sulla nostra rete (molto vasta) ci si

            gestisce perfettamente (non in modo "posticcio"

            come in ipv4) il QoS.. :-p

            Ecco, già questo è più interessante.Ed e' una delle conseguenze.... ;-)
          • FDG scrive:
            Re: Progressi
            - Scritto da: Anonimo
            E questo infatti e' uno dei modi di usarlo
            (tunnel) in questo modo infatti io ho una unica
            rete indirizzata su IPv6 pure su provider diversi
            che supportano solo IPv4
            ti pare poco?Beh, se una marea di gente non mi può raggiungere, mi pare poco. A meno che non mi interessi solo una elite di simpatici amici.
          • Anonimo scrive:
            Re: Progressi
            - Scritto da: FDG
            - Scritto da: Anonimo


            E questo infatti e' uno dei modi di usarlo

            (tunnel) in questo modo infatti io ho una unica

            rete indirizzata su IPv6 pure su provider
            diversi

            che supportano solo IPv4

            ti pare poco?

            Beh, se una marea di gente non mi può
            raggiungere, mi pare poco. A meno che non mi
            interessi solo una elite di simpatici amici.Qualcosa ti impedisce di usare tutti e due gli stack? uno per le tue esigenze e uno per gli amici? ;-)
    • The_Stinger scrive:
      Re: Progressi

      L'intero elenco di features qui illustrate a
      cominciare da IPV6
      Io lo uso da un pezzo! :-PPure io le uso da un pezzo, più precisamente da Windows 2000.Nell'articolo c'è scritto "Longhorn offrirà un nuovo stack IPv4/IPv6 integrato - ha continuato Khaki - ottimizzato per le connessioni wireless a bassa velocità e le reti multi-gigabit."Se leggi bene vuol dire non che non c'era e che l'hanno implementato ora ma che c'era già e che lo stanno sostituendo, si spera, migliorandolo.Ragazzi, ogni sistema operativo ha i suoi pro e contro, nessuno escluso, non diventiamo talebani!Linux, Windows, MacOS, Solaris, ecc... ecc...Sono solo degli strumenti, non sono dei dogma!
      • Anonimo scrive:
        Re: Progressi
        - Scritto da: The_Stinger

        L'intero elenco di features qui illustrate a

        cominciare da IPV6

        Io lo uso da un pezzo! :-P

        Pure io le uso da un pezzo, più precisamente da
        Windows 2000.

        Nell'articolo c'è scritto
        "Longhorn offrirà un nuovo stack IPv4/IPv6
        integrato - ha continuato Khaki - ottimizzato per
        le connessioni wireless a bassa velocità e le
        reti multi-gigabit."

        Se leggi bene vuol dire non che non c'era e che
        l'hanno implementato ora ma che c'era già e che
        lo stanno sostituendo, si spera, migliorandolo.

        Ragazzi, ogni sistema operativo ha i suoi pro e
        contro, nessuno escluso, non diventiamo talebani!
        Invece diventiamolo! dato che non sono tutti uguali!Certi "pregi" (ad esempio il sorgente aperto e il rispetto degli standard) valgono molto piu' di altri, non fosse cosi' oggi non avresti ne la rete ne questo forum!Mi spiace su alcuni "pregi" (per me si chiamano valori) sono talebano! :D
        • The_Stinger scrive:
          Re: Progressi

          Invece diventiamolo! dato che non sono tutti
          uguali!Per carità! Ovvio!
          Certi "pregi" (ad esempio il sorgente aperto e il
          rispetto degli standard) valgono molto piu' di
          altri, non fosse cosi' oggi non avresti ne la
          rete ne questo forum!Permettimi di correggerti.Sugli standard non si discute, ci sono tanto di RFC che li definiscono e, secondo me, un prodotto che non li rispetta tende ad andare fuori mercato.Sul sorgente aperto possiamo parlarne all'infinito ma se conosci un po' la storia dell'informatica sai che il primo scambio di bit via rete tra due macchine non è avvenuto tramite dei sistemi open source (che non esistevano).
          Mi spiace su alcuni "pregi" (per me si chiamano
          valori) sono talebano! :DMi spiace per te, io preferisco avere una visione un po' più ampia delle cose.P.S.Ci tengo a precisare che non sono un integralista Microsoft.A tutt'oggi uso e conosco (più o meno bene): Windows, Linux (sto provando un po' di distro ma quella che mi piace di più rimane SuSe), Solaris, OS/400 (il miglior sistema operativo mai progettato per un uso professionale), BeOs.Ribadisco, ogni sistema operativo ha i suoi punti di forza e le sue debolezze.
          • Anonimo scrive:
            Re: Progressi
            - Scritto da: The_Stinger

            Invece diventiamolo! dato che non sono tutti

            uguali!

            Per carità! Ovvio!


            Certi "pregi" (ad esempio il sorgente aperto e
            il

            rispetto degli standard) valgono molto piu' di

            altri, non fosse cosi' oggi non avresti ne la

            rete ne questo forum!

            Permettimi di correggerti.
            Sugli standard non si discute, ci sono tanto di
            RFC che li definiscono e, secondo me, un prodotto
            che non li rispetta tende ad andare fuori
            mercato.
            Sul sorgente aperto possiamo parlarne
            all'infinito ma se conosci un po' la storia
            dell'informatica sai che il primo scambio di bit
            via rete tra due macchine non è avvenuto tramite
            dei sistemi open source (che non esistevano).


            Mi spiace su alcuni "pregi" (per me si chiamano

            valori) sono talebano! :D

            Mi spiace per te, io preferisco avere una visione
            un po' più ampia delle cose.

            P.S.
            Ci tengo a precisare che non sono un integralista
            Microsoft.
            A tutt'oggi uso e conosco (più o meno bene):
            Windows, Linux (sto provando un po' di distro ma
            quella che mi piace di più rimane SuSe), Solaris,
            OS/400 (il miglior sistema operativo mai
            progettato per un uso professionale), BeOs.
            Ribadisco, ogni sistema operativo ha i suoi punti
            di forza e le sue debolezze.1) Visione piu' ampia? quella che si gode dal closed source? che singolare idea di "visione" ! :-)2) Secondo te la conoscenza di una "distro" vuole dire conoscere Linux?Vedo che hai strada da fare! il software con tenuto in una distro non ha granche' a che fare con l' O.S.3) OS/400 quello dell' AD/Cycle?... quello dove siccome non puoi avere piu' di 2^16 record nel DB e siccome non conosce il concetto di stream non puoi avere un Text file piu' lungo di 16 MB? ... per favoooreee! non commento per pura pieta'
          • The_Stinger scrive:
            Re: Progressi

            2) Secondo te la conoscenza di una "distro" vuole
            dire conoscere Linux?No, ma non vedo perchè, visto che sto facendo conoscenza con il mondo Linux, apprezzandolo perarltro, non vedo perchè mai dovrei compilarmi il kernel quando si trovano in giro delle ottime distribuzioni da cui cominciare.
            Vedo che hai strada da fare! il software con
            tenuto in una distro non ha granche' a che fare
            con l' O.S.Perchè? Mica gira sul vuoto cosmico.
            3) OS/400 quello dell' AD/Cycle?... quello dove
            siccome non puoi avere piu' di 2^16 record nel DB
            e siccome non conosce il concetto di stream non
            puoi avere un Text file piu' lungo di 16 MB? ...
            per favoooreee! non commento per pura pieta'Si proprio quello che ogni giorno fa girare il 90% delle borse valori di tutto il mondo.Scusa ma di che versione stai parlando?La R4V2 non mi risulta fosse affetta da questo problema e poi comunque mi devi spiegare che te ne fai di un Text file più lungo di 16 Mb (ma anche di uno più lungo di 2 Mb).Comunque non importa: alle volte mi illudo che sui forum che trattano di informatica scriva gente adulta, di solito (e questo è il caso) mi sbaglio.P.S.Alla faccia del quoting! Netiquette questa sconosciuta?
  • Anonimo scrive:
    DHCP ??
    Ma questo protocollo se non ricordo male non è più supportato nel IPv6 in quanto sono già previsti dal protocollo tutta una serie di strumenti x l'autoconfigurazione dei nodi di rete.Inoltre dall'articolo sembra che sia MS ad aver inventato tutto cio quando invece molto è gia previsto dalle RFC per IPv6 :(
    • Anonimo scrive:
      Re: DHCP ??
      Come è noto a tutti Microsoft ha EFFETTIVAMENTE inventato IPv6, nel senso che ha fatto la sua implementazione probabilmente fuori dagli standard e ostica per l'interoperabilità ed ha deciso, come suo solito, di definire QUELLA la versione "Industry standard" di IPv6.
      • FDG scrive:
        Re: DHCP ??
        - Scritto da: Anonimo
        ...nel senso che ha fatto la sua
        implementazione probabilmente fuori dagli
        standard e ostica per l'interoperabilità ed ha
        deciso, come suo solito, di definire QUELLA la
        versione "Industry standard" di IPv6.Già! Il mio ottimismo su IPv6 è finito in questo momento :(E temo che al 99% sarà così.
    • Anonimo scrive:
      Re: DHCP ??
      - Scritto da: Anonimo
      Ma questo protocollo se non ricordo male non è
      più supportato nel IPv6 in quanto sono già
      previsti dal protocollo tutta una serie di
      strumenti x l'autoconfigurazione dei nodi di
      rete.In realta`...RFC3315 : "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"Vero e` che IPv6 con Stateless Autoconfiguration permette di farsi assegnare l'indirizzo IPv6 senza DHCP, ma DHCPv6 permette di aggiungere ulteriori funzionalita` (Prefix Delegation, DNS Configuration, ...)
      Inoltre dall'articolo sembra che sia MS ad aver
      inventato tutto cio quando invece molto è gia
      previsto dalle RFC per IPv6 :(Marketing... :(
  • Anonimo scrive:
    Per la REDAZIONE...
    "Ogni qual volta ci troviamo a dover scegliere tra IPv6 e IPv4, preferiamo orientarci verso quest'ultimo", ha affermato Sanders.Ma non aveva detto il contrario un attimo prima?Refuso tipografico o refuso mentale di questo Sanders?
    • la redazione scrive:
      Re: Per la REDAZIONE...
      - Scritto da: Anonimo
      "Ogni qual volta ci troviamo a dover scegliere
      tra IPv6 e IPv4, preferiamo orientarci verso
      quest'ultimo", ha affermato Sanders.

      Ma non aveva detto il contrario un attimo prima?
      Refuso tipografico o refuso mentale di questo
      Sanders?La prima che hai detto ;-)Abbiamo corretto, grazie della segnalazione.Ciao!
  • Anonimo scrive:
    Urbani
    Dall'articolo:"Le tecnologie peer-to-peer che Microsoft ha introdotto in Windows XP" ...e chi lo dice adesso al ministrello Urbani?Sempre piu' ridicoli
    • Anonimo scrive:
      Re: Urbani
      - Scritto da: Anonimo
      Dall'articolo:
      "Le tecnologie peer-to-peer che Microsoft ha
      introdotto in Windows XP" ...
      e chi lo dice adesso al ministrello Urbani?
      Sempre piu' ridicoliNon è *quel* tipo di p2p. Non penserai mica che Zio Bill sia pro-p2p, dopo tutto quello che ha detto :)Si tratta semplicemente della tecnologia in sè, per tutti ormai p2p è sinonimo di scarico a valanga di film e musica, ma si scordano tutti che è anche una tecnologia serverless molto potente.
      • Anonimo scrive:
        Re: Urbani
        è roba tipo:stiamo chattando (peer-to-peer) e condividiamo le foto delle ferie e magari una musica mia o tua che sentiamo mentre chattiamo ma se, per esempio, la musichetta è mia, tu scordati di registrarla o risentirla a posterioria meno di usare un buon vecchio registratore 8)
        • Anonimo scrive:
          Re: Urbani
          - Scritto da: Anonimo
          è roba tipo:

          stiamo chattando (peer-to-peer) e condividiamo le
          foto delle ferie e magari una musica mia o tua
          che sentiamo mentre chattiamo ma se, per esempio,
          la musichetta è mia, tu scordati di registrarla o
          risentirla a posteriori

          a meno di usare un buon vecchio registratore 8)I soliti snobboni. Mandatevi un email e fatela finita con queste spacconate.
          • Anonimo scrive:
            Re: Urbani


            è roba tipo:



            stiamo chattando (peer-to-peer) e condividiamo
            le

            foto delle ferie e magari una musica mia o tua

            che sentiamo mentre chattiamo ma se, per
            esempio,

            la musichetta è mia, tu scordati di registrarla
            o

            risentirla a posteriori



            a meno di usare un buon vecchio registratore 8)

            I soliti snobboni. Mandatevi un email e fatela
            finita con queste spacconate.guarda che io non me ne faccio un razzo di ste roba, figurati che scrivo ancora le mail rigorosamente:- testo con font non proporzionali- quote in alto e msg in basso- a capo manuale prima del 72mo carattere con un margine d'errore dello 0.00001%8)
      • Anonimo scrive:
        Re: Urbani
        Per me peer-to-peer vuol dire "connessione attraverso un link fisico usando un protocollo di comunicazione comune fra 2 computer"Ad esempio, qualsiasi connessione ad un server web e' una connessione peer-to-peer. Ma anche usare un programma di terminale via seriale per connetterso in console ad un server! :)
        • Anonimo scrive:
          Re: Urbani
          - Scritto da: Anonimo
          Per me peer-to-peer vuol dire "connessione
          attraverso un link fisico usando un protocollo di
          comunicazione comune fra 2 computer"

          Ad esempio, qualsiasi connessione ad un server
          web e' una connessione peer-to-peer. Ma anche
          usare un programma di terminale via seriale per
          connetterso in console ad un server!
          :)Peer-to-peer è appunto connessione tra "pari", ovvero OGNI sistema svolge contemporaneamente la funzione di client e di server.
          • Anonimo scrive:
            Re: Urbani
            - Scritto da: Anonimo
            - Scritto da: Anonimo

            Per me peer-to-peer vuol dire "connessione

            attraverso un link fisico usando un protocollo
            di

            comunicazione comune fra 2 computer"



            Ad esempio, qualsiasi connessione ad un server

            web e' una connessione peer-to-peer. Ma anche

            usare un programma di terminale via seriale per

            connetterso in console ad un server!

            :)

            Peer-to-peer è appunto connessione tra "pari",
            ovvero OGNI sistema svolge contemporaneamente la
            funzione di client e di server.Ricorda che siamo su punto-informatico, quindi armati di pazienza, qua sono tutti scaricatori di porto.
          • Anonimo scrive:
            Re: Urbani

            Peer-to-peer è appunto connessione tra "pari",
            ovvero OGNI sistema svolge contemporaneamente la
            funzione di client e di server.Ni....Nella teoria vuol dire quello nella pratica una definizione più "aderente" è "ogni sistema può svolgere indifferentemente la funzione di server o di client".Il perchè è ovvio, se non fosse così un server PROXY sarebbe P2P (agisce da server per chi "proxa" e da client per i siti che contatta); semplicemente la cosa deriva dal fatto che le connessioni TCP richiedono che ci sia un lato che "è in ascolto su una certa porta" (server, ovvero serve: ascolta e aspetta) e che un altro lato inizi la connessione (client, colui che si fà servire).Si noti che in questo contesto SERVER è solo colui che ascolta mentre CLIENT colui che effettua la connessione.In un protocollo "classico" il ruolo di client e server è ben separato mentre nel P2P il programma in esecuzione è in grado di agire tanto da server quanto da client.
        • Anonimo scrive:
          Re: Urbani
          - Scritto da: Anonimo
          Per me peer-to-peer vuol dire "connessione
          attraverso un link fisico usando un protocollo di
          comunicazione comune fra 2 computer"

          Ad esempio, qualsiasi connessione ad un server
          web e' una connessione peer-to-peer. Ma anche
          usare un programma di terminale via seriale per
          connetterso in console ad un server!
          :)Uhm, non credo sia così. Altrimenti anche tu che vedi pagine su PI instaureresti un protocollo p2p. Tu scarichi una pagina html traimite un protocollo di comunicazione comune (http) dal server di PI :)Credo si riferisca ad una situazione "alla pari", diversamente dal solito concetto server-client.
        • Anonimo scrive:
          Re: Urbani
          - Scritto da: Anonimo
          Ad esempio, qualsiasi connessione ad un server
          web e' una connessione peer-to-peeresistono due modelli di comunicazione- client-servere- peer to peer
          • Anonimo scrive:
            Re: Urbani
            - Scritto da: Anonimo

            - Scritto da: Anonimo


            Ad esempio, qualsiasi connessione ad un server

            web e' una connessione peer-to-peer

            esistono due modelli di comunicazione

            - client-server

            e

            - peer to peer(newbie)Ok, definizioni corrette, però mi resta un dubbio...il protocollo usato è nel 90% dei casi coperto da copyright di varia natura, quindi nel caso di p2p si tratta comunque, a prescindere dal contenuto, di scambio di materiale coperto da copyright...Urbani che ne dice? @^
          • FDG scrive:
            Re: Urbani
            - Scritto da: Anonimo
            Urbani che ne dice? @^Prima dovresti riuscire a spiegarglielo @^
Chiudi i commenti