La disfida dei supercomputer Linux

IBM e SGI hanno vinto delle commesse per la fornitura a importanti istituti coreani e giapponesi di supercomputer basati su Linux. Nuovo fronte della competizione per conquistare la vetta della classifica Top500

Roma - Le due stesse rivali che nelle scorse settimane si sono sfidate a colpi di gigaflop, IBM e Silicon Graphics, hanno ieri annunciato di aver ottenuto contratti per la fornitura di supercomputer basati su Linux in Asia.

IBM fornirà alla Seoul National University, l'università più importante della Corea, un cluster da 425 nodi basato sui blade server JS20, i primi server ultradensi di IBM ad adottare i processori Power PC 970 (meglio noti come G5). Il sistema, che verrà installato all'interno dell'istituto coreano all'inizio del 2005, includerà lo storage server Fast 7000 di IBM e fornirà una capacità massima di elaborazione pari a 5 Teraflops.

In Giappone, presso il Japan Atomic Energy Research Institute (JAERI), SGI installerà invece un supercomputer Altix 3700 Bx2 composto da 2.048 processori Itanium 2 e circa 13 Terabyte di memoria. SGI fornirà il proprio sistemone, capace di raggiungere i 13 Teraflops, a due differenti sedi dell'ente giapponese: queste saranno connesse fra loro attraverso una rete a fibre ottiche che consentirà la condivisione dei dati fra i due supercomputer.

Sia l'Università di Seoul che il JAERI affidano attualmente le proprie necessità di calcolo a due supercomputer con una potenza nell'ordine del Teraflop.
Anche IBM ha di recente varcato i confini del Giappone installando presso l'Advanced Industrial Science and Technology (AIST) un modello di supercomputer Blue Gene/L. Ed è proprio con la sua ultima generazione di supercomputer che il colosso di Armonk conta di riappropriarsi della posizione di vertice nella classifica Top500, la cui nuova edizione semestrale verrà pubblicata l'8 novembre. Secondo alcune fonti, Big Blue dovrebbe comunicare proprio in queste ore di aver totalizzato 70 Teraflops, una potenza di calcolo che sarebbe nettamente superiore anche a quella annunciata di recente da SGI. La lotta per la prima posizione di classifica sembra dunque ancora aperta.
TAG: hw
104 Commenti alla Notizia La disfida dei supercomputer Linux
Ordina
  • Dai discorsi che vedo mi sembra di aver capito che il processore ha delle funzionalità standard (non so come si chiamano, forse diciamo l'architettura base dell'X86) e altre aggiuntive per cui è necessario qualcosa che chiamiamo driver. Quello che chiedo, e che forse è la base delle discussioni qui sotto, è: quante cose di base sono esterne all'ambito driver e si possono vedere come base. Ad esempio, ipotesi:
    a computer formattato faccio partire l'installazione dell'OS: la prima manovra non dovrebbe richiedere il driver (altrimenti chi lo mette, facciamo come l'uovo e la gallina a chi è nato prima).
    Ad un certo punto arriverà il momento di usare le funzioni aggiuntive e ora la domanda:
    senza le funzioni aggiuntive potrebbe accadere che un pentium4 venga usato come un pentium 2 o un 486 sfruttando solo la velocità e perdendo magari la possibilità di registri o istruzioni presenti solo su un processore con architettura più avanzata? In pratica queste funzioni aggiuntive possono essere istruzioni della CPU?
    ringrazio chiunque mi sappia snocciolare la domanda (senza causare flames o altro, voglio solo imparare qualcosa in più sulle CPUA bocca aperta
    non+autenticato

  • - Scritto da: Anonimo
    > Dai discorsi che vedo mi sembra di aver
    > capito che il processore ha delle
    > funzionalità standard (non so come si
    > chiamano, forse diciamo l'architettura base
    > dell'X86) e altre aggiuntive per cui
    > è necessario qualcosa che chiamiamo
    > driver. Quello che chiedo, e che forse
    > è la base delle discussioni qui
    > sotto, è: quante cose di base sono
    > esterne all'ambito driver e si possono
    > vedere come base. Ad esempio, ipotesi:
    > a computer formattato faccio partire
    > l'installazione dell'OS: la prima manovra
    > non dovrebbe richiedere il driver
    > (altrimenti chi lo mette, facciamo come
    > l'uovo e la gallina a chi è nato
    > prima).
    > Ad un certo punto arriverà il momento
    > di usare le funzioni aggiuntive e ora la
    > domanda:
    > senza le funzioni aggiuntive potrebbe
    > accadere che un pentium4 venga usato come un
    > pentium 2 o un 486 sfruttando solo la
    > velocità e perdendo magari la
    > possibilità di registri o istruzioni
    > presenti solo su un processore con
    > architettura più avanzata? In pratica
    > queste funzioni aggiuntive possono essere
    > istruzioni della CPU?

    Direi proprio di no. Istruzioni aggiuntive richiedono che il codice sia compilato apposta. Infatti se tu avessi del codice contenete istruzioni i386 queste verrebbero direttamente eseguite dal processore. Semmai il discorso si potrebbe fare con dei codici intermedi eseguiti tramite una virtual machine, ma a quel punto sarebbe la virtual machine a distinguere il tipo di processore.
    L'unica utilità quindi è accedere a funzionalità tipo il risparmio energetico (abbassamento del clock). Nella mia ignoranza però non saprei dirti se tali funzionalità pur riguardando ovviamente la CPU, vadano ad agire direttamente sulla CPU stessa oppure sulla scheda madre.

    non+autenticato
  • - Scritto da: Anonimo

    > driver. Quello che chiedo, e che forse
    > è la base delle discussioni qui
    > sotto, è: quante cose di base sono
    > esterne all'ambito driver e si possono
    > vedere come base. Ad esempio, ipotesi:
    > ...
    > Ad un certo punto arriverà il momento
    > di usare le funzioni aggiuntive e ora la
    > domanda:
    > senza le funzioni aggiuntive potrebbe
    > accadere che un pentium4 venga usato come un
    > pentium 2 o un 486 sfruttando solo la
    > velocità e perdendo magari la
    > possibilità di registri o istruzioni
    > presenti solo su un processore con
    > architettura più avanzata? In pratica
    > queste funzioni aggiuntive possono essere
    > istruzioni della CPU?

    Riguardo alla velocita` no, nel senso che una CPU piu` moderna fa girare piu` velocemente anche sistemi operativi e software compilati per versioni piu` vecchie di quella famiglia di CPU.
    Perche` ad ogni nuova versione di CPU ci sono miglioramenti anche nell'architettura, in particolare il numero di pipeline, le singole unita` di esecuzione e soprattutto la quantita` di cache la sua velocita` e il suo schema di riempimento e di accesso.

    Istruzioni aggiuntive ed ottimizzazioni particolari se sfruttate danno quei punti percentuali in piu` che dipendono dalla tipologia del software.
    Ti faccio qualche esempio:
    Se compili per una versione piu` vecchia di una CPU come il 386 o il 68000 (di Motorola) sarai certo che il software girera` per tutte le versioni di quelle CPU fino ad oggi (Pentium M e 68060/Coldfire) e future. E giovera` comunque di tutte le innovazioni che hanno avuto quelle CPU ma solo sull`architettura base.
    Tutte le estensioni multimediali e ottimizzazioni particolari non saranno usate.

    Ora le prestazioni che si avrebbero in piu` utilizzando estensioni nuove e funzioni particolari di una CPU dipendono dal tipo di software che scrivi. Se e` un software gestionale o di utility generica non avra` alcun giovamento se durante la compilazione viene ottimizzato per le estensioni di una nuova CPU. Se invece e` un software di ingegneria o di grafica 3D o di elaborazione audio/video allora otimizzarlo per istruzioni SSE ed MMX puo fargli aumentare le prestazioni da 10 al 50%.

    Ma l'ottimizzazione a tutti i costi comporta un problema importante, la possibilita` che quel software non sara` compatibile con versioni precedenti della CPU per la quale e` stato compilato.

    Tutto sta a quale e` lo scopo del software e che risultato si vuole ottenere.

    Nel mondo opensource sei avvantaggiato dal fatto che la maggior parte del software si puo` compilare per la CPU che hai sul tuo PC e farlo puo` migliorare di molto le prestazioni per alcune tipologie di software.
    La migliore distribuzione in tal senso e` la Gentoo dove ogni pacchetto che si installa va compilato al momento.
    Altrimenti ci si puo` rivolgere a distribuzioni che hanno un'ottimizzazione i686 (per il mondo x86) almeno per il kernel e l'ambiente grafico.

    Queste distribuzioni ovviamente non funzionano su 386/486 o K6-II e CyrixM2.

    Windows sostituisce in fase d'installazione o anche dinamicamente, se si sposta il disco su pc diversi quelle estensioni che qualcuno in questo forum ha voluto chiamare "driver", per la CPU in cui sta girando.
    Windows essendo un prodotto commerciale per utenza poco tecnica deve poter girare su una quantita` maggiore di CPU compresi i 486. Evidentemente per fare cio` e` poco ottimizzato in fase di compilazione ed le estensioni multimediali le applica tramite estensioni esterne al "core" del kernel.

    --
    Ciao.
    Mr. Mechano

    ==================================
    Modificato dall'autore il 07/11/2004 18.45.20
  • Allora,

    Il concetto che hai espresso non tiene conto del fatto che a differenza dei sistemi precompilati come Windows o le distribuzioni Linux che sei abituato a vedere, qui stiamo parlando di un sistema open source, in cui sia il compilatore che il kernel sono modificabili.

    Linux, come tutti i sistemi operativi multipiattaforma, ha parti dipendenti dall' architettura che (puoi vedere nell' alberatura dei sorgenti del kernel) e parti di livello piu` alto, scritte in C.

    La parte in C e` ricompilabile con una versione di gcc in cui come target e` stato indicato il processore destinazione.

    La parte dipendente dall' architettura va comunque adeguata.

    Ottenuto questo primo passaggio il kernel viene "eseguito" dal boot loader e carica tutta l' infrastruttura per fare funzionare la macchina, senza necessita` di drivers, poi ovviamente non gira su altre architetture.

    Ovviamente vi possono essere delle parti del processore che hanno funzioni specifiche, come la gestione degli interrupt o cose simili nel qual caso potrebbe, non obbligatoriamente essere presente qualche device di gestione che comunque va scritto e integrato nel kernel.

    Il problema dell' uovo e la gallina viene risolto mediante la cross-compilazione.


    non+autenticato

  • - Scritto da: Anonimo
    > Allora,
    >
    > Il concetto che hai espresso non tiene conto
    > del fatto che a differenza dei sistemi
    > precompilati come Windows o le distribuzioni
    > Linux che sei abituato a vedere, qui stiamo
    > parlando di un sistema open source, in cui
    > sia il compilatore che il kernel sono
    > modificabili.
    >
    > Linux, come tutti i sistemi operativi
    > multipiattaforma, ha parti dipendenti dall'
    > architettura che (puoi vedere nell'
    > alberatura dei sorgenti del kernel) e parti
    > di livello piu` alto, scritte in C.
    >
    > La parte in C e` ricompilabile con una
    > versione di gcc in cui come target e` stato
    > indicato il processore destinazione.
    >
    > La parte dipendente dall' architettura va
    > comunque adeguata.
    >
    > Ottenuto questo primo passaggio il kernel
    > viene "eseguito" dal boot loader e carica
    > tutta l' infrastruttura per fare funzionare
    > la macchina, senza necessita` di drivers,
    > poi ovviamente non gira su altre
    > architetture.
    >
    > Ovviamente vi possono essere delle parti del
    > processore che hanno funzioni specifiche,
    > come la gestione degli interrupt o cose
    > simili nel qual caso potrebbe, non
    > obbligatoriamente essere presente qualche
    > device di gestione che comunque va scritto e
    > integrato nel kernel.
    >
    > Il problema dell' uovo e la gallina viene
    > risolto mediante la cross-compilazione.


    >-----

    http://en.wikipedia.org/wiki/Cross-compilation

    Cross-compilation



    From Wikipedia, the free encyclopedia.

    Compiling a program takes place by running the compiler on the build platform. The compiled program will run on the target platform. Usually these two are the same; if they are different, the process is called cross-compilation.

    Typically the hardware architecture differs, like for example when compiling a program destined for the MIPS architecture on a X86 computer; but cross-compilation is also applicable when only the operating system environment differs, as when compiling a FreeBSD program under GNU/Linux.

    Cross-compilation is somewhat more involved and errors are easier to make than with normal compilation. Due to this it is normally only employed if the target is not yet self-hosting (able to compile programs on its own), unstable, or the build system is simply much faster. For many embedded systems cross-compilation is the only possible way (some may be not powerful enough to run a compiler).

    ---<

    non+autenticato
  • > funzionalità standard (non so come si
    > chiamano, forse diciamo l'architettura base
    > dell'X86) e altre aggiuntive per cui
    > è necessario qualcosa che chiamiamo
    > driver.
    Dunque, semplificando, esistono famiglie di processori.
    Una famiglia di processori condivide delle istruzioni di base che sono sufficienti a fare girare sistemi operativi e software.
    Un amd o intel moderno ad esempio contengono le istruzioni di un 386 e fanno quindi parte della stessa famiglia, possono fare girare qualunque software (sempre semplificando) con le istruzioni per 386.
    Questo non vuole dire che girino come un 386 a n GHz, ciascun processore è fatto a suo modo per ottimizzare l'esecuzione del codice della famiglia, quindi è possibile avere risultati diversi come efficienza anche eseguendo solo il codice generico per 386.
    A questo si aggiunge la possibilità di ottimizzare il codice per una data architettura, cioè di fare scrivere al compilatore del codice più amichevole per una data sottofamiglia di macchine (esempio 486 o più, pentium o più...), il codice così generato però rischia di essere inefficiente o incomprensibile per macchine diverse, specie per macchine di sottofamiglie più vecchie.
    Questa ottimizzazione si basa su conoscere ad esempio come una cosa una data sottofamiglia o modello gestisce la predizione delle operazioni, quanta cache ha, quali operazioni fa meglio, sostituendo l'ASM generato con uno appropriato, ad esempio trovando algoritmi analoghi per fare la stessa cosa ma più veloci su quella data cpu.
    Migliorando l'esecuzione del codice della famiglia, questo tipo di ottimizzazione porta a guadagnare pochi punti percentuali, ma su tutto il codice scritto... a complicare ulteriormente la faccendo c'è il fatto che alcune architetture possono migliorare su certe operazioni e peggiorare su altre, quindi il miglioramento non è facile da esaminare e non è uniforme.
    (c'è anche un tipo di ottimizzazione generica, su molti compilatori, che prescinde dal tipo di cpu utilizzata, che analizza in modo abb simile a quanto espresso prima, quale sia il modo migliore per esprimere un algoritmo, di solito si abilitano livelli di analisi più approfondita, quindi di PROBABILI maggiori ottimizzazioni, su richiesta perchè ovviamente questo lavoro richiede tempo di compilazione aggiuntivo per vagliare le varie ipotesi).
    Come ulteriore livello di ottimizzazione poi a volte le nuove architetture portano nuove istruzioni, come le mmx, sse1 e 2 per le cpu intel; le nuove istruzioni sono in genere nate come risposta a problemi specifici, ad esempio il multimediale, che non erano sentiti come oggi quando fu sviluppata la famiglia di cpu x86. A seconda degli strumenti di sviluppo le istruzioni aggiuntive possono essere chiamate esplicitamente o abilitate in modo più o meno non trasparente per semplificare lo sviluppo. Ovviamente se queste istruzioni non esistono su di un dato processore non possono essere eseguite, al massimo, ma non sempre, possono esistere strumenti di sviluppo che a fronte di una data chiamata controllino se la cpu targhet la supporti e in caso contrario la sostituiscano con una routine di istruzioni generiche.
    L'ottimizzazione tramite istruzioni aggiuntive può essere determinante per le prestazioni, ad esempio è possibile lavorare su 4, 8 o più interi o floating per volta, quasi moltiplicando le performance della cpu, ma limitatamente a quel determinato tipo di operazione.
    Non tutti i problemi si prestano ad essere risolti tramite le istruzioni aggiuntive, così la grossa base del sw risulta scritto, non per incuria, con il generico codice per 386 (o per le altre famiglie per cpu diverse). In pratica queste istruzioni in grado di aumentare di un ordine di grandezza le prestazioni sono workaround specifici per determinati tipi di problemi, che possono essere determinanti per alcuni tipi di software ma non per tutti.
    Un approcio diverso è l'ottimizzazione manuale, ovvero scrivere ditrettamente il codice ASM che la macchina eseguirà, in pratica facendo manualemente il lavoro di ottimizzazione che farebbe il compliatore, a volte questo tipo di approcio è necessario (per esempio Tanenbaum e Torvalds hanno scritto diversi pezzi rispettivamente di Minix e di Linux direttamente nei vari ASM delle piattaforme supportate per migliorarne le prestazioni), a volte ininfluente (se gli algoritmi sono semplici e non ci sono molte alternative di solito il compliatore non ha molte possibilità di sbagliare!).
    In questo caso è necessario però la compilazione condizionale, con delle direttive al compilatore (anche inserite direttamente nel codice) verrà compilato il "pezzo" scritto nell'ASM specifico, se supportato (ciascuno andrà scriotto e mantenuto, moltiplicando il lavoro necessario per gestire il sw), con magari sempre una alternativa generica in un linguaggio di alto livello per dare una versione compilabile per le architetture non supportate o non previste.
    Questo tipo di ottimizzazione può essere tanto del tipo "istruzioni di base" quanto "istruzioni specifiche", uno si scrive il codice che vuole.

    > Quello che chiedo, e che forse
    > è la base delle discussioni qui
    > sotto, è: quante cose di base sono
    > esterne all'ambito driver e si possono
    > vedere come base.
    Con le istruzioni di base il sistema operativo fa tutto. Ricompilandolo per la data piattaforma si attivano le ottimizzazioni sul codice generico per sottofamiglia o modello, col guadagno in molte parti del sistema, di diversi punti percentuali, o anche eventuali parti di ASM ottimizzato manualemente per un dato targhet, sia conteneti istruzioni generiche che aggiuntive. Le istruzioni aggiuntive, es. multimediali, a livello di sistema operativo di solito non è che siano fondamentali, a quanto so, comunque se ci sono delle parti di sw scritte in modo specifico per le istruzioni specifiche della piattaforma, con la ricompilazione si attivano, nel senso che si troveranno negli eseguibili ricompilati.
    Questo non è da confondere con le ottimizzazioni che si possono fare a ragion veduta conoscendo il proprio sistema e togliendo di mezzo parti del sistema che non servono, riducendo alcuni timeout ecc ecc...
    In questo modo è proprio il sw che viene reso più performante (non è nemmeno semplice fare una comparazione, dipende dalle differenze introdotte!) adattandolo alle proprie esigenze, ma ovviamente non sono decisioni da prendere alla leggera, come invece è abbastanza semplice decidere di ricompilare il sistema tale quale è indicando semplicemente la cpu targhet.
    Oltre a questo, in senso lato, ci sono altre caratteristiche del processore che oggi cominciano ad essere importanti e che il sistema dovrebbe sapere come gestire, come ad esempio la gestione del risparmio energetico (sui centrino influenza anche la quantità di cache L2 resa disponibile), delle temperature e del voltaggio (oggi non più demandate alla sk madre).

    ==================================
    Modificato dall'autore il 08/11/2004 10.18.50
    non+autenticato
  • Leggendo l'altro post...
    i driver per i processori NON ESISTONO!!! SVEGLIA!!!
    Si parla di compilazione del kernel con target x86 - K7 - K8 - Pentium, ecc...

    Riflettete, su cosa lo caricate il driver del processore? su un altro processore?A bocca aperta

    Non fatevi confondere da windows, quell'icona che vedete è soltanto indicativa del tipo di cpu che avete.

    STOP.

  • - Scritto da: TrollSpammer
    > Leggendo l'altro post...
    > i driver per i processori NON ESISTONO!!!
    > SVEGLIA!!!
    > Si parla di compilazione del kernel con
    > target x86 - K7 - K8 - Pentium, ecc...
    >
    > Riflettete, su cosa lo caricate il driver
    > del processore? su un altro processore?A bocca aperta
    >
    > Non fatevi confondere da windows,
    > quell'icona che vedete è soltanto
    > indicativa del tipo di cpu che avete.
    >
    > STOP.

    Ma stop che ? Un altro fanatico che sentenzia senza sapere di cosa parla.
    Evidentemente l'inglese non lo sai leggere, altrimenti avresti dato un'occhiata ai link ed avresti capito il funzionamento dei driver per processori.

    Su questo forum c'è gente che mitizza, facendosi forte della parola Linux, il significato di driver... è triste vedere tanta supponenza.

    Un driver che abilita funzioni in una CPU è un driver, come altro vorresti chiamarlo ?

    I DSP della Creative su Live! e Audigy si attivano caricando tramite driver dall' OS il firmware, per quanto è dato sapere visto che la documentazione completa non è pubblica ma solo per sviluppatori, tuttavia questo fatto è stato più volte confermato dalla Creative in vari forum. Come lo chiameresti il driver del DSP che attiva il DSP stesso caricando il firmware ?

    Fossi in te mi darei una letta alle specifiche ACPI collegate a PowerNow!, OnNow, SpeedStep , forse impareresti qualcosa.
    Ma tu ed altri pro-Linux supponenti immagino vogliate insegnare all'industria il significato di driver e dirgli che sbagliano ad usarlo su documenti ufficiali delle specifiche per programmatori e progettisti, vero ?Triste
    non+autenticato
  • - Scritto da: Anonimo
    > Ma stop che ? Un altro fanatico che
    > sentenzia senza sapere di cosa parla.
    > Evidentemente l'inglese non lo sai leggere,
    > altrimenti avresti dato un'occhiata ai link
    > ed avresti capito il funzionamento dei
    > driver per processori.

    Rileggiti meglio il link, quella è una feature aggiuntiva.

    > Su questo forum c'è gente che
    > mitizza, facendosi forte della parola Linux,
    > il significato di driver... è triste
    > vedere tanta supponenza.

    E' triste vedere tanta ignoranza, mentre ti fai forte di un link di MS di cui tu stesso per primo non hai capito il senso. Gli altri lo hanno letto, tranquillo, ma guardacaso nessuno ti da' ragione. Chiediti perchè. Tutti scemi?

    > Un driver che abilita funzioni in una CPU
    > è un driver, come altro vorresti
    > chiamarlo ?

    E la CPU come fa ad abilitare delle funzioni della CPU, se non sono stati caricati questi driver?A bocca aperta

    > I DSP della Creative su Live! e Audigy si
    > attivano caricando tramite driver dall' OS

    Si ma che c'entra? Creative e Audigy fanno CPU o schede audio?A bocca aperta

    > Fossi in te mi darei una letta alle
    > specifiche ACPI collegate a PowerNow!,
    > OnNow, SpeedStep , forse impareresti
    > qualcosa.

    Sono tutte cose aggiuntive! Non tutti i pc li hanno!!!

    > Ma tu ed altri pro-Linux supponenti immagino
    > vogliate insegnare all'industria il
    > significato di driver e dirgli che sbagliano
    > ad usarlo su documenti ufficiali delle
    > specifiche per programmatori e progettisti,
    > vero ?Triste

    No, sei tu che pretendi di dimostrare l'esistenza di una cosa che non esiste! Non esistono i driver per la CPU!
    non+autenticato

  • -----<

    http://diablo.national.com/GIDE/DOCs/COP8/Generate...

    CPU driver
    The CPU driver is generated for the target CPU bean (in comparison to other bean drivers). The CPU driver contains additionally:
    MCU initialization code
    interrupt processing

    >----

    - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > Ma stop che ? Un altro fanatico che
    > > sentenzia senza sapere di cosa parla.
    > > Evidentemente l'inglese non lo sai
    > leggere,
    > > altrimenti avresti dato un'occhiata ai
    > link
    > > ed avresti capito il funzionamento dei
    > > driver per processori.
    >
    > Rileggiti meglio il link, quella è
    > una feature aggiuntiva.
    >
    > > Su questo forum c'è gente che
    > > mitizza, facendosi forte della parola
    > Linux,
    > > il significato di driver... è
    > triste
    > > vedere tanta supponenza.
    >
    > E' triste vedere tanta ignoranza, mentre ti
    > fai forte di un link di MS di cui tu stesso
    > per primo non hai capito il senso. Gli altri
    > lo hanno letto, tranquillo, ma guardacaso
    > nessuno ti da' ragione. Chiediti
    > perchè. Tutti scemi?
    >
    > > Un driver che abilita funzioni in una
    > CPU
    > > è un driver, come altro vorresti
    > > chiamarlo ?
    >
    > E la CPU come fa ad abilitare delle funzioni
    > della CPU, se non sono stati caricati questi
    > driver?A bocca aperta
    >
    > > I DSP della Creative su Live! e Audigy
    > si
    > > attivano caricando tramite driver dall'
    > OS
    >
    > Si ma che c'entra? Creative e Audigy fanno
    > CPU o schede audio?A bocca aperta
    >
    > > Fossi in te mi darei una letta alle
    > > specifiche ACPI collegate a PowerNow!,
    > > OnNow, SpeedStep , forse impareresti
    > > qualcosa.
    >
    > Sono tutte cose aggiuntive! Non tutti i pc
    > li hanno!!!
    >
    > > Ma tu ed altri pro-Linux supponenti
    > immagino
    > > vogliate insegnare all'industria il
    > > significato di driver e dirgli che
    > sbagliano
    > > ad usarlo su documenti ufficiali delle
    > > specifiche per programmatori e
    > progettisti,
    > > vero ?Triste
    >
    > No, sei tu che pretendi di dimostrare
    > l'esistenza di una cosa che non esiste! Non
    > esistono i driver per la CPU!
    non+autenticato

  • - Scritto da: Anonimo

    > -----<
    >
    > diablo.national.com/GIDE/DOCs/COP8/GeneratedC
    >
    > CPU driver
    > The CPU driver is generated for the target
    > CPU bean (in comparison to other bean
    > drivers). The CPU driver contains
    > additionally:
    > MCU initialization code
    > interrupt processing
    >
    > >----

    Dall'avvento della tecnologia VLSI sempre piu` spinta ormai i chip di controllo di funzioni periferiche hanno delle vere e proprie CPU programmabili.
    Porte seriali, controller SCSI e schede audio che prima avevano solo convertitori AD/DA ora hanno CPU con DSP integrato.

    Quindi e` facile anche per un pischello di 15 anni mettere su Google le parole driver+cpu e trovare decine di documenti che hanno le due parole associate.

    I firmware uploadabili che nomini in altri post sono una cosa totalmente differente da quello che riporti tu.
    Il firmware e` un modo di agganciare codice precompilato ad un driver opensource o anche commerciale senza fornirne la versione sorgente agli sviluppatori.
    Quando progetti chip con funzioni interessanti, e` molto importante arrivare un po` prima della concorrenza e tenerla lontana il maggior tempo possibile.
    La fuga piu` importante di informazioni per un produttore OEM proviene dagli sviluppatori delle schede.

    E moltissimi produttori si trovano molto a disagio davanti alla grande diffusione di Linux e dell'opensource e la sua diffusione li obbliga a rilasciare driver Linux per i proprio prodotti. Peccato che un driver software per il mondo opensource sottintenda anche la disponibilita` dei sorgenti, per mille motivi. E un produttore e` obbligato a supportare almeno 3-4 distribuzioni principali per almeno 3 architetture piu` importanti.

    La tecnica del firmware e` stato l'uovo di colombo. Fornire i sorgenti di sole parti marginali dell'hardware e il binario di controllo piu` importante precompilato e uploadabile sotto forma di firmware. La Intel ha molti prodotti cosi`, come le sue schede WiFi e i winmodem. Anche nVidia sta seguendo questa strada.

    E` un accrocco di dubbia efficienza, ma sembra funzionare e protegge gli investimenti delle aziende hardware.

    La parola Driver ormai ha un'accezione talmente generica che confonderlo con un componente che serve alla CPU centrale di un computer e` un errore che puo` fare solo un programmatore molto giovane e tu devi esserlo, e anche ingenuo, per non capire cosa e` un firmware uploadabile.

    --
    Mr. Mechano

  • - Scritto da: Mechano
    >
    > - Scritto da: Anonimo
    >
    > > -----<
    > >
    > >
    > diablo.national.com/GIDE/DOCs/COP8/GeneratedC
    > >
    > > CPU driver
    > > The CPU driver is generated for the
    > target
    > > CPU bean (in comparison to other bean
    > > drivers). The CPU driver contains
    > > additionally:
    > > MCU initialization code
    > > interrupt processing
    > >
    > > >----
    >
    > Dall'avvento della tecnologia VLSI sempre
    > piu` spinta ormai i chip di controllo di
    > funzioni periferiche hanno delle vere e
    > proprie CPU programmabili.
    > Porte seriali, controller SCSI e schede
    > audio che prima avevano solo convertitori
    > AD/DA ora hanno CPU con DSP integrato.

    Allora ?


    > Quindi e` facile anche per un pischello di
    > 15 anni mettere su Google le parole
    > driver+cpu e trovare decine di documenti che
    > hanno le due parole associate.

    Ovviamente stai tentando di insultarmi. A parte che non è neanche fuochino ma proprio acqua, direi pieno oceano... ma tu i link di riferimento che la gente ti porta li leggi o sai solo sparare sentenze a caso ?

    > I firmware uploadabili che nomini in altri
    > post sono una cosa totalmente differente da
    > quello che riporti tu.
    > Il firmware e` un modo di agganciare codice
    > precompilato ad un driver opensource o anche
    > commerciale senza fornirne la versione
    > sorgente agli sviluppatori.

    Cosa, cosa , cosa ??? Che sarebbe un firmware ? Un modo di agganciare codice ??!?!?
    Ma dico, ma stai scherzando o dici sul serio ?
    E secondo te i DSP come funzionano e come si programmano, per magia ?
    Il lettore DVD da tavolo che la gente compra nel supermercato a 49 euro o meno secondo te il firmware ce l'ha per cosa, agganciare codice precompilato ?!?!

    Senti, tu evidentemente non sai di cosa parli.

    > Quando progetti chip con funzioni
    > interessanti, e` molto importante arrivare
    > un po` prima della concorrenza e tenerla
    > lontana il maggior tempo possibile.
    > La fuga piu` importante di informazioni per
    > un produttore OEM proviene dagli
    > sviluppatori delle schede.


    "chip con funzioni interessanti" .. che frase da dotti , eh? Peccato che non dica nulla, vuole essere tanto pomposa ma è totalmente vuota, priva di ogni significato.
    Quali sarebbero i chip privi di funzioni interessanti ? Che intendi per funzioni interessanti ? Mah, lo sai solo tu, grande esperto saccente so-tutto-io !


    > E moltissimi produttori si trovano molto a
    > disagio davanti alla grande diffusione di
    > Linux e dell'opensource e la sua diffusione
    > li obbliga a rilasciare driver Linux per i
    > proprio prodotti. Peccato che un driver
    > software per il mondo opensource sottintenda
    > anche la disponibilita` dei sorgenti, per
    > mille motivi. E un produttore e` obbligato a
    > supportare almeno 3-4 distribuzioni
    > principali per almeno 3 architetture piu`
    > importanti.


    Sì, vabbè, sogna con le tue fandonie sull'open-source che mette a disagio i produttori... ma per favore !


    > La tecnica del firmware e` stato l'uovo di
    > colombo. Fornire i sorgenti di sole parti
    > marginali dell'hardware e il binario di
    > controllo piu` importante precompilato e
    > uploadabile sotto forma di firmware. La
    > Intel ha molti prodotti cosi`, come le sue
    > schede WiFi e i winmodem. Anche nVidia sta
    > seguendo questa strada.

    Ma che dici ? Guarda che anche il BIOS dei PC è in pratica un firmware, cosa pensi che sia ?
    Stai facendo una confusione incredibile.
    Che pensi, che più cose dici e più impressioni quelli che non sanno e/o si lasciano incantare dalle tue acrobazie linguistiche (secondo me pure pessime) ?


    > E` un accrocco di dubbia efficienza, ma
    > sembra funzionare e protegge gli
    > investimenti delle aziende hardware.

    Cosa ? Un accrocco di dubbia efficienza ?
    Guarda, tu evidentemente non sai di cosa stai parlando e non hai mai visto del codice DSP in vita tua. Figurarsi sistemi embedded o altro... Lascia perdere, che è meglio. Con questa frase qui sopra hai toccato il fondo, grande esperto saccente !
    Di farmi insultare e dare dell'ignorante da uno che dice queste stupidaggini come te proprio non lo accetto.


    > La parola Driver ormai ha un'accezione
    > talmente generica che confonderlo con un
    > componente che serve alla CPU centrale di un
    > computer e` un errore che puo` fare solo un
    > programmatore molto giovane e tu devi
    > esserlo, e anche ingenuo, per non capire
    > cosa e` un firmware uploadabile.
    >
    > --
    > Mr. Mechano

    Sì, continua ad insultare. Spero di non dover mai incontrare gente con la tua ignoranza al lavoro perchè altrimenti dovrei sobbarcarmi anche tutto quello che uno come te non sa fare pur di portare a termine un lavoro di squadra... Non oso immaginare uno come te a comandare giovani programmatori che danni possa fare...
    Tu non hai la più pallida idea di cosa sia un firmware nè un driver. Non hai proprio idea di come funzionano le cose nè al livello software nè hardware.
    Prenditi dei libri decenti ed inizia a studiare le basi se vuoi evitare di dire castronerie.

    non+autenticato

  • --------->


    http://www.spinics.net/lists/kernel/msg310003.html

    [RFC/PATCH 0/4] cpus, nodes, and the device model: dynamic cpu registration

    --------------------------------------------------------------------------------

    To: linux-kernel@vger.kernel.org
    Subject: [RFC/PATCH 0/4] cpus, nodes, and the device model: dynamic cpu registration
    From: Nathan Lynch
    Date: Sun, 24 Oct 2004 03:42:10 -0600
    Cc: greg@kroah.com, rusty@rustcorp.com.au, mochel@digitalimplant.org, Nathan Lynch , anton@samba.org
    Sender: linux-kernel-owner@vger.kernel.org

    --------------------------------------------------------------------------------

    Hi there-

    I know of at least two platforms (ppc64 and ia64) which allow cpus to
    be physically or logically added and removed from a running system.
    These are distinct operations from onlining or offlining, which is
    well supported already. Right now there is little support in the core
    cpu "driver" for dynamic addition or removal. The patch series which
    follows implements support for this in a way which will (hopefully)
    reduce code duplication and enforce some uniformity across the
    relevant architectures.

    For starters, the current situation is that cpu sysdevs are registered
    from architecture code at boot. Already we have inconsistencies
    betweeen the arches -- ia64 registers only online cpus, ppc64
    registers all "possible" cpus. I propose to move the initial cpu
    sysdev registrations to the cpu "driver" itself (drivers/base/cpu.c),
    and to register only "present" cpus at boot.

    But that breaks all the arch code which explicitly registers cpu
    sysdevs. For instance, ppc64 wants to hang all kinds of attributes
    off of the cpu devices for performance counter stuff. So code such as
    this needs to be converted to register a sysdev_driver with the cpu
    device class, which will allow the ppc64 code to be notified when a
    cpu is added or removed. In the patches that follow I include the
    changes necessary for ppc64, as an example. (An arch sweep or
    temporary compatibility hack can come later if I get positive
    responses to this approach.)

    Also, there is the matter of the base numa "node" driver. Currently
    the cpu driver makes symlinks from nodes to their cpus. This seems
    backwards to me, so I have changed the node driver to create or remove
    the symlinks upon cpu addition or removal, respectively, also using
    the sysdev_driver approach. I've also converted base/drivers/node.c
    to doing the boot-time node registration itself, like the cpu code.

    Finally, I've added two new interfaces which wrap all this up --
    cpu_add() and cpu_remove(). These carry out the necessary update to
    cpu_present_map and take care of the cpu device registration. These
    are meant to be invoked from the platform-specific code which
    discovers and removes processors.

    This is the first real device model-related hacking I've done. I'm
    hoping Greg or Patrick will tell me whether I'm on the right track or
    abusing the APIsSorride

    These patches have been boot-tested on ppc64. I haven't gotten to
    test the removal paths yet.


    Nathan
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/








    <-----------



    - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > Ma stop che ? Un altro fanatico che
    > > sentenzia senza sapere di cosa parla.
    > > Evidentemente l'inglese non lo sai
    > leggere,
    > > altrimenti avresti dato un'occhiata ai
    > link
    > > ed avresti capito il funzionamento dei
    > > driver per processori.
    >
    > Rileggiti meglio il link, quella è
    > una feature aggiuntiva.
    >
    > > Su questo forum c'è gente che
    > > mitizza, facendosi forte della parola
    > Linux,
    > > il significato di driver... è
    > triste
    > > vedere tanta supponenza.
    >
    > E' triste vedere tanta ignoranza, mentre ti
    > fai forte di un link di MS di cui tu stesso
    > per primo non hai capito il senso. Gli altri
    > lo hanno letto, tranquillo, ma guardacaso
    > nessuno ti da' ragione. Chiediti
    > perchè. Tutti scemi?
    >
    > > Un driver che abilita funzioni in una
    > CPU
    > > è un driver, come altro vorresti
    > > chiamarlo ?
    >
    > E la CPU come fa ad abilitare delle funzioni
    > della CPU, se non sono stati caricati questi
    > driver?A bocca aperta
    >
    > > I DSP della Creative su Live! e Audigy
    > si
    > > attivano caricando tramite driver dall'
    > OS
    >
    > Si ma che c'entra? Creative e Audigy fanno
    > CPU o schede audio?A bocca aperta
    >
    > > Fossi in te mi darei una letta alle
    > > specifiche ACPI collegate a PowerNow!,
    > > OnNow, SpeedStep , forse impareresti
    > > qualcosa.
    >
    > Sono tutte cose aggiuntive! Non tutti i pc
    > li hanno!!!
    >
    > > Ma tu ed altri pro-Linux supponenti
    > immagino
    > > vogliate insegnare all'industria il
    > > significato di driver e dirgli che
    > sbagliano
    > > ad usarlo su documenti ufficiali delle
    > > specifiche per programmatori e
    > progettisti,
    > > vero ?Triste
    >
    > No, sei tu che pretendi di dimostrare
    > l'esistenza di una cosa che non esiste! Non
    > esistono i driver per la CPU!
    non+autenticato

  • - Scritto da: Anonimo

    > well supported already. Right now there is
    > little support in the core
    > cpu "driver" for dynamic addition or
    > removal. The patch series which
    > follows implements support for this in a way

    Ahahahahaahahaha
    Lo stesso sviluppatore che ha scritto il draft tecnico ha messo la parola "driver" tra virgolette per identificare qualcosa che un driver non e` ma che ha funzioni simili o che lui non saprebbe definire diversamente!

    Ah l'informatica e le sue 1000 sfumature, e i pischelli classe '85 cresciuti solo con Winzozz.

    --
    Mr. Mechano
  • ----------->


    http://lwn.net/Articles/10656/


    Patch: driver model updates


    From:   Patrick Mochel
    To:   torvalds@transmeta.com
    Subject:   [BK PATCH] driver model updates
    Date:   Mon, 23 Sep 2002 18:45:26 -0700 (PDT)
    Cc:   linux-kernel@vger.kernel.org



    Hey there.

    Here is the latest round of driver model infrastructure updates. To
    summarize, these changes do:

    - Add system bus type, and struct sys_device for system-level devices.
    - convert i8259.c and time.c to use this interface. This gives us in
    driverfs:

    [mochel@cherise mochel]$ tree -d /sys/bus/system/
    /sys/bus/system/
    |-- devices
    |   |-- pic0 -> ../../../root/sys/pic0
    |   `-- rtc0 -> ../../../root/sys/rtc0
    `-- drivers
        |-- cpu
        `-- pic


    - add struct cpu, a default CPU driver, and a CPU device class.
    - Register CPU devices on boot, which gives us in driverfs:

    [mochel@cherise mochel]$ tree -d /sys/class/cpu/
    /sys/class/cpu/
    |-- devices
    |   |-- 0 -> ../../../root/sys/cpu0
    |   `-- 1 -> ../../../root/sys/cpu1
    `-- drivers







    <----------

    - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > Ma stop che ? Un altro fanatico che
    > > sentenzia senza sapere di cosa parla.
    > > Evidentemente l'inglese non lo sai
    > leggere,
    > > altrimenti avresti dato un'occhiata ai
    > link
    > > ed avresti capito il funzionamento dei
    > > driver per processori.
    >
    > Rileggiti meglio il link, quella è
    > una feature aggiuntiva.
    >
    > > Su questo forum c'è gente che
    > > mitizza, facendosi forte della parola
    > Linux,
    > > il significato di driver... è
    > triste
    > > vedere tanta supponenza.
    >
    > E' triste vedere tanta ignoranza, mentre ti
    > fai forte di un link di MS di cui tu stesso
    > per primo non hai capito il senso. Gli altri
    > lo hanno letto, tranquillo, ma guardacaso
    > nessuno ti da' ragione. Chiediti
    > perchè. Tutti scemi?
    >
    > > Un driver che abilita funzioni in una
    > CPU
    > > è un driver, come altro vorresti
    > > chiamarlo ?
    >
    > E la CPU come fa ad abilitare delle funzioni
    > della CPU, se non sono stati caricati questi
    > driver?A bocca aperta
    >
    > > I DSP della Creative su Live! e Audigy
    > si
    > > attivano caricando tramite driver dall'
    > OS
    >
    > Si ma che c'entra? Creative e Audigy fanno
    > CPU o schede audio?A bocca aperta
    >
    > > Fossi in te mi darei una letta alle
    > > specifiche ACPI collegate a PowerNow!,
    > > OnNow, SpeedStep , forse impareresti
    > > qualcosa.
    >
    > Sono tutte cose aggiuntive! Non tutti i pc
    > li hanno!!!
    >
    > > Ma tu ed altri pro-Linux supponenti
    > immagino
    > > vogliate insegnare all'industria il
    > > significato di driver e dirgli che
    > sbagliano
    > > ad usarlo su documenti ufficiali delle
    > > specifiche per programmatori e
    > progettisti,
    > > vero ?Triste
    >
    > No, sei tu che pretendi di dimostrare
    > l'esistenza di una cosa che non esiste! Non
    > esistono i driver per la CPU!
    non+autenticato
  • ------------->

    http://lists.freebsd.org/pipermail/freebsd-arch/20...

    Common device driver classes?
    John Baldwin jhb at FreeBSD.org
    Thu Dec 11 13:44:10 PST 2003

    Previous message: Common device driver classes?
    Next message: Common device driver classes?
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    --------------------------------------------------------------------------------

    On 11-Dec-2003 Nate Lawson wrote:
    > I'm in the middle of implementing various drivers and all of them have the
    > same problem. I want to have a generic set of functionality that is
    > provided in various hardware specific ways. The two drivers I'm working
    > on are a cpu freq driver (hw-specific drivers: speedstep, longrun, acpi
    > px, amd64) and a laptop buttons/control driver (hw-specific drivers:
    > toshiba, asus, apm).
    >
    > Let's take clock frequency manipulation as an example. There might be a
    > sysctl like "hw.cpu.0.freq" that can be set to change the clock frequency.
    > The actual transition would be handled by a hardware-specific driver that
    > would program the right registers for SpeedStep, for instance.
    >
    > The various drivers would also need to set priorities for how they attach.
    > For instance, certain drivers may implement subsets of other drivers'
    > functionality. If so, the attach routine would return -100 for the simple
    > drivers and 0 for the full-featured ones. If one driver returns -100 and
    > another returns 0, the sysctl function handler should point to the second
    > driver and the first should not be called since it has been superseded.
    >
    > Since this sounds like newbus, here's an example how this might work:
    >
    >     cpubusXXX
    >         cpu0
    >             cpufreq (speedstep) - hw.cpu.0.freq
    >         cpu1
    >             cpufreq (acpi performance states) - hw.cpu.1.freq
    >
    > Note that cpu0 might also support ACPI performance states but speedstep is
    > a more accurate driver for the given hardware. The user could change the
    > frequency for each CPU through a generic sysctl without knowing the
    > underlying technology used to make the transition.
    >
    > Finally, the probe/attach routines of each driver should be called for
    > each logical processor in the system and would then call cpuid or other
    > things for that processor to determine what capabilities it has.
    > Wouldn't we need a bus layer for CPU drivers to hang off of that was
    > filled out by our CPU enumeration?

    Yes, you will need some sort of bus layer. It shouldn't be impossible
    to do. You could have a cpubus that hangs off of root0 (stick it in
    kern/subr_smp.c maybe) and then each MD arch could provide a CPU driver
    in mp_machdep.c that has an identify routine that adds cpu objects for
    each CPU in system to cpubus. Either that or you could drop cpubus
    altogether, and just have cpuX hang directly off of root0, or off of
    something like nexus0 if that's what you want to do. I can do a sample
    implementation for i386 that creates cpu drivers and hangs them off of
    nexus0 for i386 if you would like.

    --

    John Baldwin   < http://www.FreeBSD.org/~jhb/
    "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/







    <----------




    - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > Ma stop che ? Un altro fanatico che
    > > sentenzia senza sapere di cosa parla.
    > > Evidentemente l'inglese non lo sai
    > leggere,
    > > altrimenti avresti dato un'occhiata ai
    > link
    > > ed avresti capito il funzionamento dei
    > > driver per processori.
    >
    > Rileggiti meglio il link, quella è
    > una feature aggiuntiva.
    >
    > > Su questo forum c'è gente che
    > > mitizza, facendosi forte della parola
    > Linux,
    > > il significato di driver... è
    > triste
    > > vedere tanta supponenza.
    >
    > E' triste vedere tanta ignoranza, mentre ti
    > fai forte di un link di MS di cui tu stesso
    > per primo non hai capito il senso. Gli altri
    > lo hanno letto, tranquillo, ma guardacaso
    > nessuno ti da' ragione. Chiediti
    > perchè. Tutti scemi?
    >
    > > Un driver che abilita funzioni in una
    > CPU
    > > è un driver, come altro vorresti
    > > chiamarlo ?
    >
    > E la CPU come fa ad abilitare delle funzioni
    > della CPU, se non sono stati caricati questi
    > driver?A bocca aperta
    >
    > > I DSP della Creative su Live! e Audigy
    > si
    > > attivano caricando tramite driver dall'
    > OS
    >
    > Si ma che c'entra? Creative e Audigy fanno
    > CPU o schede audio?A bocca aperta
    >
    > > Fossi in te mi darei una letta alle
    > > specifiche ACPI collegate a PowerNow!,
    > > OnNow, SpeedStep , forse impareresti
    > > qualcosa.
    >
    > Sono tutte cose aggiuntive! Non tutti i pc
    > li hanno!!!
    >
    > > Ma tu ed altri pro-Linux supponenti
    > immagino
    > > vogliate insegnare all'industria il
    > > significato di driver e dirgli che
    > sbagliano
    > > ad usarlo su documenti ufficiali delle
    > > specifiche per programmatori e
    > progettisti,
    > > vero ?Triste
    >
    > No, sei tu che pretendi di dimostrare
    > l'esistenza di una cosa che non esiste! Non
    > esistono i driver per la CPU!
    non+autenticato
  • -------->

    http://darwinsource.opendarwin.org/10.0.4/AppleHea...

    // Method: setPowerState
    //
    // VERY IMPORTANT NOTE:
    // sleepState(bool) can be called from here or directly. This is NOT an oversight.
    // What I am trying to resolve here is a problem with those powerbooks that have
    // 2 Heathrow chips. In these machines the main Heathrow should be powered on
    // in the CPU driver, and the second here. Since the HeathrowState holds a bit
    // to remeber if the state is valid, and such a bit is cleared once the state is
    // restored I am sure that I am not going to overwrite a valid state with an (older)
    // invalid one.
    IOReturn Heathrow::setPowerState(unsigned long powerStateOrdinal, IOService* whatDevice)



    <--------

    - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > Ma stop che ? Un altro fanatico che
    > > sentenzia senza sapere di cosa parla.
    > > Evidentemente l'inglese non lo sai
    > leggere,
    > > altrimenti avresti dato un'occhiata ai
    > link
    > > ed avresti capito il funzionamento dei
    > > driver per processori.
    >
    > Rileggiti meglio il link, quella è
    > una feature aggiuntiva.
    >
    > > Su questo forum c'è gente che
    > > mitizza, facendosi forte della parola
    > Linux,
    > > il significato di driver... è
    > triste
    > > vedere tanta supponenza.
    >
    > E' triste vedere tanta ignoranza, mentre ti
    > fai forte di un link di MS di cui tu stesso
    > per primo non hai capito il senso. Gli altri
    > lo hanno letto, tranquillo, ma guardacaso
    > nessuno ti da' ragione. Chiediti
    > perchè. Tutti scemi?
    >
    > > Un driver che abilita funzioni in una
    > CPU
    > > è un driver, come altro vorresti
    > > chiamarlo ?
    >
    > E la CPU come fa ad abilitare delle funzioni
    > della CPU, se non sono stati caricati questi
    > driver?A bocca aperta
    >
    > > I DSP della Creative su Live! e Audigy
    > si
    > > attivano caricando tramite driver dall'
    > OS
    >
    > Si ma che c'entra? Creative e Audigy fanno
    > CPU o schede audio?A bocca aperta
    >
    > > Fossi in te mi darei una letta alle
    > > specifiche ACPI collegate a PowerNow!,
    > > OnNow, SpeedStep , forse impareresti
    > > qualcosa.
    >
    > Sono tutte cose aggiuntive! Non tutti i pc
    > li hanno!!!
    >
    > > Ma tu ed altri pro-Linux supponenti
    > immagino
    > > vogliate insegnare all'industria il
    > > significato di driver e dirgli che
    > sbagliano
    > > ad usarlo su documenti ufficiali delle
    > > specifiche per programmatori e
    > progettisti,
    > > vero ?Triste
    >
    > No, sei tu che pretendi di dimostrare
    > l'esistenza di una cosa che non esiste! Non
    > esistono i driver per la CPU!
    non+autenticato
  • quando creano bestie come quelle assumono programmatori seri che prendono il kernel e creano una versione seria di linux. Che non possano usare windows dipende da questo. Windows non possono smontarlo. Se andate a vedere quelle versioni di linux vedrete che è altra roba, non la robaccia che gira su desktop. Non credo che per far partire tutti i processori vadano sui forum a cercare il driver
    non+autenticato
  • > assumono
    > programmatori seri che prendono il kernel e
    > creano una versione seria di linux.

    Prendo atto che i programmatori del kernel linux non sono seri. Prendo atto che il kernel linux non è serio.

    Corro dal mio capo a dire che dobbiamo assolutamente togliere dagli 11 server cha gestisco, Linux in favore di un sistema serio.

    :pFan Linux

    PS. La prossima volta usa i termini "ottimizzato" "su misura" e "personalizzato" e lascia il "serio" alle persone serie
    non+autenticato

  • - Scritto da: Anonimo
    > > assumono
    > > programmatori seri che prendono il
    > kernel e
    > > creano una versione seria di linux.
    >
    > Prendo atto che i programmatori del kernel
    > linux non sono seri. Prendo atto che il
    > kernel linux non è serio.
    >
    > Corro dal mio capo a dire che dobbiamo
    > assolutamente togliere dagli 11 server cha
    > gestisco, Linux in favore di un sistema
    > serio.
    >
    >Con la lingua fuoriFan Linux
    >
    > PS. La prossima volta usa i termini
    > "ottimizzato" "su misura" e "personalizzato"
    > e lascia il "serio" alle persone serie

    Evidentemente non sai di cosa parli. Linux è una delle peggiori scopiazzature Unix in giro. IBM può permettersi di riscriverlo da zero se vuole, è una delle multinazionali che ha inventato Unix ed il suo AIX è anni luce avanti rispetto a quanto i pro-Linux potranno mai aspirare di essere.
    FreeBSD è molto meglio di Linux, assolutamente--almeno se uno sa di cosa parla ed ha studiato qualche base di Unix.

    non+autenticato
  • infatti IBM vende soluzioni basate su linux, molte più di quelle basate su AIX
    Tutte le aziende che si stanno interessando a linux forse dovrebbero fare quattro chiacchere con te che gli spieghi qualche base di unix
    non+autenticato

  • - Scritto da: Anonimo
    > infatti IBM vende soluzioni basate su linux,
    > molte più di quelle basate su AIX
    > Tutte le aziende che si stanno interessando
    > a linux forse dovrebbero fare quattro
    > chiacchere con te che gli spieghi qualche
    > base di unix

    Evidentemente sei ottuso. Chi è che usa Linux ? Chi vuole risparmiare e chi vuole lucrarci sul risparmio.
    Chi vuole sistemi high-end seri con OS Unix non installerà mai Linux.
    non+autenticato
  • ehm... a me pareva di stare parlando sul forum della notizia di linux su due supercomputer... non sull'orologio da ploso....
    ma chiaramente la demenza ti assale....
    non+autenticato

  • - Scritto da: Anonimo
    > Chi vuole sistemi high-end seri con OS Unix
    > non installerà mai Linux.

    ...veramente un nutrito numero di Supercomputer nella top500 utilizza Linux... se devi trollare almeno cerca di non farti sputtanare in 4 secondi...

    Fan Apple
    non+autenticato
  • - Scritto da: Anonimo

    > Evidentemente sei ottuso. Chi è che
    > usa Linux ? Chi vuole risparmiare e chi
    > vuole lucrarci sul risparmio.

    Mah, io ci vedo anche:

    chi vuole essere libero di modificare il codice e coi prodotti closed non lo puo' fare;

    chi non vuole essere obbligato ad aggiornare con cavilli tipici del mondo del software commerciale: l'obsolescenza programmata;

    chi vuole essere certo che i propri dati siano al sicuro e che non restino impelagati in formati proprietari o addirittura rubati da spyware e simili, difficili da trovare se non ci sono i sorgenti;

    chi vuole partecipare allo sviluppo, vedere il proprio nome inciso per sempre nel codice di Linux e sentirsi parte di una comunita' speciale;

    chi cerca prestazioni superiori grazie alla possibilita' di adattare il software alle proprie esigenze o poter ottimizzare e ricompilare kernel, driver e programmi per la propria applicazione mission critical.

    > Chi vuole sistemi high-end seri con OS Unix
    > non installerà mai Linux.

    A me pare che gli unici che installano Unix commerciali al posto di Linux sono solo coloro che necessitano di un supporto e servizio d'assistenza, se lo possono permettere e lo preferiscono al posto della formazione di personale interno.

    E chi necessita di sistemi high-end spesso non ha difficolta' a trovare e pagare esperti Linux, ergo anche e soprattutto in queste realta' si sceglie sempre di piu' Linux.

    --
    Mr. Mechano
    mechano@punto-informatico.it
  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > infatti IBM vende soluzioni basate su
    > linux,
    > > molte più di quelle basate su AIX
    >
    > Evidentemente sei ottuso. Chi è che
    > usa Linux ? Chi vuole risparmiare e chi
    > vuole lucrarci sul risparmio.
    > Chi vuole sistemi high-end seri con OS Unix
    > non installerà mai Linux.

    Ma visto che AIX è di IBM che problema avrebbe IBM a dare AIX ad un prezzo più basso invece di dare Linux?
    non+autenticato
  • > Evidentemente non sai di cosa parli. Linux
    > è una delle peggiori scopiazzature
    > Unix in giro. IBM può permettersi di
    > riscriverlo da zero se vuole,

    vabbhè, non è che significhi molto.

    > è una
    > delle multinazionali che ha inventato Unix
    > ed il suo AIX è anni luce avanti
    > rispetto a quanto i pro-Linux potranno mai
    > aspirare di essere.

    Premesso che AIX è una figata incredibile, che è a 64bit da una vita ecc... all'atto pratico che ti permette di fare che con linux non puoi fare?

    > FreeBSD è molto meglio di Linux,
    > assolutamente--almeno se uno sa di cosa
    > parla ed ha studiato qualche base di Unix.

    Idem... con Free (o gli altri xBSD) che è che puoi fare in più che con linux?

    Grazie delle risposte,
    Ciao

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > > assumono
    > > > programmatori seri che prendono il
    > > kernel e
    > > > creano una versione seria di linux.
    > >
    > > Prendo atto che i programmatori del
    > kernel
    > > linux non sono seri. Prendo atto che il
    > > kernel linux non è serio.
    > >
    > > Corro dal mio capo a dire che dobbiamo
    > > assolutamente togliere dagli 11 server
    > cha
    > > gestisco, Linux in favore di un sistema
    > > serio.
    > >
    > >Con la lingua fuoriFan Linux
    > >
    > > PS. La prossima volta usa i termini
    > > "ottimizzato" "su misura" e
    > "personalizzato"
    > > e lascia il "serio" alle persone serie
    >
    > Evidentemente non sai di cosa parli. Linux
    > è una delle peggiori scopiazzature
    > Unix in giro. IBM può permettersi di
    > riscriverlo da zero se vuole, è una
    > delle multinazionali che ha inventato Unix
    > ed il suo AIX è anni luce avanti
    > rispetto a quanto i pro-Linux potranno mai
    > aspirare di essere.
    > FreeBSD è molto meglio di Linux,
    > assolutamente--almeno se uno sa di cosa
    > parla ed ha studiato qualche base di Unix.
    >

    Visto che la tua conoscenza dei *nix è così vasta , perchè non ti studi anche cosa vouol dire GNU Occhiolino e non cominci a dire che linux è solo il kernel....

    Barone dello Zwanlandshire
    Fan Linux
    non+autenticato
  • ... in cantina: scope, spazzole e tanta polvere!!!!!!
    non+autenticato
  • - Scritto da: Anonimo
    > ... in cantina: scope, spazzole e tanta
    > polvere!!!!!!

    Seeee il giorno che faranno un megacomputer windows ne riparliamo... sai che spettacolo... avremo i megawormA bocca aperta
    non+autenticato

  • - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > ... in cantina: scope, spazzole e tanta
    > > polvere!!!!!!
    >
    > Seeee il giorno che faranno un megacomputer
    > windows ne riparliamo... sai che
    > spettacolo... avremo i megawormA bocca aperta

    L'hanno già fatto... sul pianeta Arrakis (Dune)...

    http://www.citilink.com/~rmc/dune/worm.htm
    non+autenticato
  • Ahahahah ci pensi che figata un superworm?
    non+autenticato
  • la velocità non si misura in teraflops ma in teraimailps: milioni di email infette al secondo....
    non+autenticato

  • - Scritto da: Anonimo
    > la velocità non si misura in
    > teraflops ma in teraimailps: milioni di
    > email infette al secondo....

    1000 miliardi di email al sec
    non+autenticato
  • ecco la differenze tra i super esperti linux e gli utonti windows. I primi neanche sanno le unità di misura

    kilo 10^3
    mega 10^6
    giga 10^9
    tera 10^12
    peta 10^15
    exa 10^18
    yotta 10^21

    andiamo bene, studia prima di sparare
    non+autenticato

  • - Scritto da: Anonimo
    > ecco la differenze tra i super esperti linux
    > e gli utonti windows. I primi neanche sanno
    > le unità di misura
    >
    > kilo 10^3
    > mega 10^6
    > giga 10^9
    > tera 10^12
    > peta 10^15
    > exa 10^18
    > yotta 10^21
    >
    > andiamo bene, studia prima di sparare


    tu devi essere un esperto linux visto che non le conosci...
    zetta (Z) 10^21
    yotta (Y) 10^24

    se cerchi i drivers delle CPU per il tuo computer come cerchi le unità di misura, presto li troverai...Occhiolino

    mi raccomando installali
    setup.exe (avanti, avanti, avanti, avanti, avanti, fine)
    Fan Linux
    non+autenticato

  • - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > ... in cantina: scope, spazzole e tanta
    > > polvere!!!!!!
    >
    > Seeee il giorno che faranno un megacomputer
    > windows ne riparliamo... sai che
    > spettacolo... avremo i megawormA bocca aperta

    si, ridi, ridi pure... tanto il worm per linuzzo arriverà, e si che arriverà...
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > - Scritto da: Anonimo
    > > > ... in cantina: scope, spazzole e
    > tanta
    > > > polvere!!!!!!
    > >
    > > Seeee il giorno che faranno un
    > megacomputer
    > > windows ne riparliamo... sai che
    > > spettacolo... avremo i megawormA bocca aperta
    >
    > si, ridi, ridi pure... tanto il worm per
    > linuzzo arriverà, e si che
    > arriverà...

    forse fra 20 anni
    http://www.google.com/press/zeitgeist/jun04_pie.gi...
    non+autenticato

  • - Scritto da: Anonimo
    > - Scritto da: Anonimo
    > > ... in cantina: scope, spazzole e tanta
    > > polvere!!!!!!
    >
    > Seeee il giorno che faranno un megacomputer
    > windows ne riparliamo... sai che
    > spettacolo... avremo i megawormA bocca aperta

    intanto goditi pure i trojan per linux

    http://www.azpoint.net/news/Software_News_9124.asp
    non+autenticato