Caso IBM, SCO vuole due processi

SCO ha chiesto al tribunale che la questione sui copyright venga disgiunta dall'attuale processo e gestita da un'altra giuria. IBM ha invece sollecitato a considerare nulle le accuse di SCO


Salt Lake City (USA) – Con una nuova istanza ], SCO Group ha chiesto al tribunale che l’attuale causa con IBM venga separata in due distinti processi: uno dedicato alla questione relativa ai copyright, ed uno dedicato alle questioni di natura prettamente contrattuale.

La violazione di copyright si è aggiunta ai capi d’accusa di SCO soltanto lo scorso febbraio: prima di questa data la causa verteva principalmente sulla violazione di contratto e il furto di segreti industriali (quest’ultima “cause of action” è stata di recente depennata).

SCO sostiene che le due questioni, quella sui brevetti e quella sui contratti di licenza, oltre a non essere correlate, rischiano di rendere la causa troppo complessa, e vadano pertanto risolte “con processi separati e da giurie separate”.

“Due processi a sé stanti – conclude l’istanza di SCO – potranno prevenire ritardi, impedire che la giuria venga influenzata o confusa, ed economizzare le risorse giudiziarie”.

Nell’eventuale processo “parallelo” a quello attuale, SCO vorrebbe trasferire anche alcune controquerele presentate lo scorso anno da IBM e relative alla violazione di brevetti.

Nel suo nuovo documento, presentato ad una corte federale dell’Utah, SCO non ha alterato in alcun modo le sue allegazioni: queste, com’è ormai noto, sono incentrate sugli accordi di licenza con IBM e sul reclamo dei copyright di alcune porzioni di codice che IBM avrebbe travasato in Linux da AIX e Dynix, due sistemi operativi basati sul codice di UNIX.

Negli scorsi giorni IBM ha invece chiesto alla corte, con un aggiornamento di una sua controquerela, una sentenza che stabilisca che “IBM non ha infranto, indotto all’infrazione o contribuito all’infrazione di nessun copyright di SCO attraverso le proprie attività legate a Linux, incluso il suo uso, la riproduzione e il miglioramento di Linux, e che alcuni o tutti i pretesi copyright di SCO su UNIX sono invalidi e non suscettibili di tutela giudiziaria”.

Con tale richiesta IBM spera che il giudice rigetti le argomentazioni di SCO relative ai copyright prima ancora che entrino nel merito del processo.

IBM ha anche eliminato dalla propria controquerela una delle accuse che lo scorso anno aveva avanzato contro SCO: la violazione di un metodo brevettato per la navigazione fra i menù grafici ad albero.

Nel proprio documento Big Blue ha poi informato la corte di aver registrato nove nuovi copyright relativi ad alcune delle tecnologie riversate in Linux, fra cui il supporto al file-system JFS.

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

  • avvelenato scrive:
    Re: benchmark a 64bits
    - Scritto da: Anonimo

    E' vero che un programma per un RISC occupa
    più istruzioni, ma non è per
    questo meno veloce di un corrispondente
    CISC, il fatto è che i RISC hanno un
    architettura più semplice e questo
    rende possibile un uso più efficiente
    della pipeline

    un link
    www.lithium.it/articolo.asp?code=20&pag=6 sì sì lo sapevo, (cmq grazie x il link, anche se già lo conoscevo), era solo per chiarirsi, a volte ne nascono diatribe infinite su cosa è cisc e cosa non lo è... due palle! per me l'acronimo si spiega benissimo, e se non è complesso un set di 200istruzioni, allora ce ne vogliono duemila per poterlo definire complesso? :D
  • Anonimo scrive:
    Re: benchmark a 64bits
    - Scritto da: Anonimo

    Non credo proprio sia scorretto definirli
    CISC.
    CISC = Complex Instruction Set Computer
    e viste le oltre 200 istruzioni di un
    pentium senza contare quelle per mmx, sse,
    sse2 ecc.... la vedo dura a chiamarli RISC.
    RISC = Reduced Instruction Set Computer
    Il solo fatto che abbiano incluso alcune
    caratteristiche tipiche dei RISC non li fa
    diventare a tutti gli effetti CISC. ^^^^^RISC intendevo
  • Anonimo scrive:
    Re: benchmark a 64bits
    - Scritto da: avvelenato
    ps: ma mi dicevano che per gli x86 è
    oramai poco sensato usare il termine cisc,
    ma è tanto scorretto usarlo? in
    fondo, anche nel caso in cui integrino un
    alpha+traduttore (non so quale famiglia usi
    quest'architettura), all'esterno rimane
    sempre una cpu-cisc, concettualmente, o no?Non credo proprio sia scorretto definirli CISC.CISC = Complex Instruction Set Computer e viste le oltre 200 istruzioni di un pentium senza contare quelle per mmx, sse, sse2 ecc.... la vedo dura a chiamarli RISC.RISC = Reduced Instruction Set Computer Il solo fatto che abbiano incluso alcune caratteristiche tipiche dei RISC non li fa diventare a tutti gli effetti CISC.E' vero che un programma per un RISC occupa più istruzioni, ma non è per questo meno veloce di un corrispondente CISC, il fatto è che i RISC hanno un architettura più semplice e questo rende possibile un uso più efficiente della pipelineun linkhttp://www.lithium.it/articolo.asp?code=20&pag=6
  • avvelenato scrive:
    Re: I 64 bit una fregatura?
    apparte che fintantoché non si vedono dei bench sarebbe inutile parlare, cmq le cpu di AMD sono ottime nel 32, e questo indipendentemente dalla loro potenza nel 64bits.per il resto, a molti la potenza serve, ad altri fa comodo ma non è indispensabile, d'altra parte non è un mistero che ogni componente sw, anche il più complesso, potrebbe costare anche 1? al pezzo con una produzione in vasta scala.. il punto è che per ridurre i costi bisogna aumentare le tirature,e questo si può fare solo aumentando la domanda.
  • avvelenato scrive:
    Re: benchmark a 64bits
    - Scritto da: Anonimo

    - Scritto da: Anonimo


    La cache di secondo livello e' solo
    dati,

    non istruzioni. Quindi le differenze
    sono

    molto piu' piccole del 15%.

    Ma per favore, non diciamo castronerie!

    Anche se il meccanismo di caching e' di tipo
    esclusivo (minimizzazione dei "doppioni"
    tra le varie cache) la L2 puo contenere sia
    dati che istruzioni.uh, e io che pensavo di aver trovato la risposta!
  • avvelenato scrive:
    Re: benchmark a 64bits
    - Scritto da: Anonimo

    - Scritto da: avvelenato


    aspetto che qualche tecnico più

    esperto di me confermi!

    Quello che hai detto e' valido per una cpu
    in cui
    tra modalita a 32bit e modalita a 64bit
    cambia
    solo la lunghezza in bit dei registri e la
    dimensione
    dei dati immediati e degli offset nelle
    istruzioni
    che diventano per default a 64bit
    (con conseguenza che a parita di algoritmo
    viene
    richiesto molto piu spazio per memorizzare
    il codice da eseguire e viene richiesto piu
    spazio
    per memorizzare i dati in cache).

    Gli x86-64 hanno parecchi assi nella manica
    introdotti nel modo a 64bit che aiutano ad
    alzare ulteriormente le prestazioni.

    In modo 64bit l''indirizzamento di default
    e' a 64bit
    ma la dimensione di default dei dati e' 32bit
    (in modo tale che le combinazioni dati &
    indirizzamento
    piu utilizzate siano anche quelle piu
    compatte).

    Vengono raddoppiati *in numero* tutti
    i registri prevedibilmente piu utilizzati
    (quindi ci sono piu dati elaborati a massima
    velocita
    senza toccare le cache).

    Inoltre (e paradossalmente) a causa del
    formato delle
    istruzioni x86-64 uno stesso programma (a
    livello di sorgente)
    in forma binaria e' in media piu compatto
    ripetto a delle cpu RISC a 64bit (ed
    enormemente piu
    compatto rispetto agli Itanium), questo
    permette di sfruttare
    meglio la cache L1 e di stressare meno
    il resto del sistema per caricare istruzioni
    (la complicazione "aggiuntiva" a livello di
    decoder
    che ci deve essere comunque per eseguire
    anche il codice a x86 32bit in compenso
    permette
    di avere "gratis" istruzioni "compatte" nel
    formato a 64bit).beh è risaputo che le risc hanno dei programmoni giganteschi laddove con quattro istruzioni cisc risolvi tutto. :) ovviamente il mio confronto è tra architettura x86-32bits e x86-64ps: ma mi dicevano che per gli x86 è oramai poco sensato usare il termine cisc, ma è tanto scorretto usarlo? in fondo, anche nel caso in cui integrino un alpha+traduttore (non so quale famiglia usi quest'architettura), all'esterno rimane sempre una cpu-cisc, concettualmente, o no?
  • Anonimo scrive:
    Re: I 64 bit una fregatura?
    - Scritto da: Anonimo

    - Scritto da: sigsegv


    I 64 bit servono praticamente solo ad

    indirizzare più di 4 gigabyte di

    memoria. Oggi per i desktop servono a
    pochi

    (nessuno?), ma sicuramente non è

    più una dimensione
    fantascientifica.

    Quando le DIMM da 4Gb saranno diffuse e
    costeranno come lo sono state le simm da 4Mb
    nel 96-97 allora sara' il momento di
    comprare CPU a 64 bit che costeranno
    un'80ina di euro.
    Prima di allora non serviranno a nessuno.
    Concordo con voi sul fatto che i 64 bit ora come ora non possano servire più di tanto (oddio, alcuni famosi videogame di adesso hanno mostrato le prime ottimizzazioni in questo senso, vedi Far Cry)... ma la cosa più ovvia che mi balza nella mente è che se non volete aggiornarvi, semplicemente non fatelo... qualcuno ve lo impone? Queste sono solo seghe mentali.. chi lo vuole se lo prende.. io personalmente credo che per questo Natale faro parte della schiera dei 64 bit, fate vobis.
  • Anonimo scrive:
    64 bit serve a chi ne ha bisogno
    ad esempio in ambito scientificohttp://www.democritos.it/activities/IT-MC/talks/talk-computer.pdfinoltre "High performance servers, database management systems, CAD workstations, and even common desktops will benefit from a 64-bit design""The k8 also expands the amount of available CPU registers, thus offering faster computational performance than current CPU designs do.""Processor intensive software functions, such as graphics transform and lighting, circuit simulation, and scientific processing will directly benefit from the x86-64 architecture. Combined with native support for 16- and 32-bit software, the AMD K8 will prove to be a very competitive platform."http://sysopt.earthweb.com/articles/k8/index.html
  • Anonimo scrive:
    Re: benchmark a 64bits
    - Scritto da: Anonimo
    La cache di secondo livello e' solo dati,
    non istruzioni. Quindi le differenze sono
    molto piu' piccole del 15%.Ma per favore, non diciamo castronerie!Anche se il meccanismo di caching e' di tipoesclusivo (minimizzazione dei "doppioni"tra le varie cache) la L2 puo contenere siadati che istruzioni.
  • Anonimo scrive:
    Re: I 64 bit una fregatura?
    - Scritto da: sigsegv
    I 64 bit servono praticamente solo ad
    indirizzare più di 4 gigabyte di
    memoria. Oggi per i desktop servono a pochi
    (nessuno?), ma sicuramente non è
    più una dimensione fantascientifica.Quando le DIMM da 4Gb saranno diffuse e costeranno come lo sono state le simm da 4Mb nel 96-97 allora sara' il momento di comprare CPU a 64 bit che costeranno un'80ina di euro.Prima di allora non serviranno a nessuno.
  • sigsegv scrive:
    Re: I 64 bit una fregatura?
    - Scritto da: Anonimo
    Io credo al complotto. Credo che i 64bit
    introdotti in un mercato dove non servono a
    nessuno (quello desktop) sia l'ennesima
    espressione di obsolescenza programmata e
    invito per gli utenti a rinnovare
    l'hardware.I 64 bit servono praticamente solo ad indirizzare più di 4 gigabyte di memoria. Oggi per i desktop servono a pochi (nessuno?), ma sicuramente non è più una dimensione fantascientifica.
  • Anonimo scrive:
    I 64 bit una fregatura?
    Quando arrivarono le prime CPU a 64 bit si e' partiti subito coi benchmark, quelli fatti in modo serio hanno dato risultati deludenti, la CPU a 64bit ha senso sui server dove e' necessario trattare enormi database.A livello di velocita' sui desktop o si hanno dimensioni enormi di cache di 2° e 3° livello o le prestazioni sono anche inferiori.Da qualche giorno a questa parte i benchmark "seri" sono spariti. Li fanno poche riviste e non vengono qusi mai presi in considerazione. In pubblicita' e presentazioni si fa quasi sempre riferimento a quelli ufficiali dei produttori del chip, come quando si chiede all'oste se il vino e' buono.Da un 5-10% in meno di prestazioni dei vecchi benchmark ora si parla di percentuali altissime di guadagno.Io credo al complotto. Credo che i 64bit introdotti in un mercato dove non servono a nessuno (quello desktop) sia l'ennesima espressione di obsolescenza programmata e invito per gli utenti a rinnovare l'hardware.
  • avvelenato scrive:
    Re: benchmark a 64bits
    - Scritto da: Anonimo

    - Scritto da: avvelenato


    Comunque, questo significa che i
    512kbyte di

    cache su utilizzo 32bits valgono di

    più rispetto agli stessi su
    64bits, o

    detto più chiaramente, l'arch. a
    64

    bits richiederebbe più cache.

    La cache di secondo livello e' solo dati,
    non istruzioni. Quindi le differenze sono
    molto piu' piccole del 15%.ciò mi rassicura.
  • Anonimo scrive:
    Re: benchmark a 64bits
    - Scritto da: avvelenato
    Comunque, questo significa che i 512kbyte di
    cache su utilizzo 32bits valgono di
    più rispetto agli stessi su 64bits, o
    detto più chiaramente, l'arch. a 64
    bits richiederebbe più cache.La cache di secondo livello e' solo dati, non istruzioni. Quindi le differenze sono molto piu' piccole del 15%.
  • Anonimo scrive:
    Tabella delle pagine
    In questo sistema quanto è grande la tabelle delle pagine e in quanti livelli è suddivisa? 3?
  • avvelenato scrive:
    Re: benchmark a 64bits
    - Scritto da: carbonio

    - Scritto da: avvelenato

    Penso sia necessario standardizzare una

    ratifica universalmente accettata di

    benchmark a 64bits, così da
    valutare

    le prestanze di queste cpu.
    CUT

    Scusa la domanda un po' ingenua, ma non sono
    così afferrato nello specifico campo
    (sarà anche l'ora che non mi aiuta).

    Intendi dire che con Bench per 64bit
    risulterebbe più lento?
    non proprio.intendo dire che, se in una CPU x86-64 con 1mega di cache, l'incremento prestazionale di un programma progettato e compilato per 64bits può essere più efficiente (ipoteticamente) del 45% rispetto alla stessa versione a 32bits, una cpu simile in clock ma con 512mega di cache, potrebbe avere un incremento del 35% nel passaggio dai 32 ai 64... cioé in pratica la cache viene usata di più in modalità a 64 bits, di quanto non lo so bene e comunque dipende da programma a programma, però potrebbe anche essere che un quantitativo di cache appena sufficiente per la modalità a 32bits (ad esempio il Paris ne ha 256) magari (ma è solo un ipotesi!) a 64bits non avrebbe sufficiente spazio, e avrebbe bisogno di accedere alla RAM più frequentemente (e le RAM comportano alcune latenze d'accesso), con il risultato di peggiorare le prestazioni, anziché migliorarle.aspetto che qualche tecnico più esperto di me confermi!
    • carbonio scrive:
      Re: benchmark a 64bits
      intanto ti ringrazio del chiarimento(anche se per capirlo bene è meglio che me lorilegga domani;))
    • Anonimo scrive:
      Re: benchmark a 64bits
      - Scritto da: avvelenato
      aspetto che qualche tecnico più
      esperto di me confermi!Quello che hai detto e' valido per una cpu in cuitra modalita a 32bit e modalita a 64bit cambiasolo la lunghezza in bit dei registri e la dimensionedei dati immediati e degli offset nelle istruzioniche diventano per default a 64bit(con conseguenza che a parita di algoritmo viene richiesto molto piu spazio per memorizzare il codice da eseguire e viene richiesto piu spazio per memorizzare i dati in cache).Gli x86-64 hanno parecchi assi nella manicaintrodotti nel modo a 64bit che aiutano adalzare ulteriormente le prestazioni.In modo 64bit l''indirizzamento di default e' a 64bitma la dimensione di default dei dati e' 32bit(in modo tale che le combinazioni dati & indirizzamento piu utilizzate siano anche quelle piu compatte).Vengono raddoppiati *in numero* tuttii registri prevedibilmente piu utilizzati(quindi ci sono piu dati elaborati a massima velocita senza toccare le cache).Inoltre (e paradossalmente) a causa del formato delleistruzioni x86-64 uno stesso programma (a livello di sorgente)in forma binaria e' in media piu compattoripetto a delle cpu RISC a 64bit (ed enormemente piucompatto rispetto agli Itanium), questo permette di sfruttaremeglio la cache L1 e di stressare menoil resto del sistema per caricare istruzioni(la complicazione "aggiuntiva" a livello di decoder che ci deve essere comunque per eseguire anche il codice a x86 32bit in compenso permettedi avere "gratis" istruzioni "compatte" nel formato a 64bit).
  • carbonio scrive:
    Re: benchmark a 64bits
    - Scritto da: avvelenato
    Penso sia necessario standardizzare una
    ratifica universalmente accettata di
    benchmark a 64bits, così da valutare
    le prestanze di queste cpu.CUTScusa la domanda un po' ingenua, ma non sonocosì afferrato nello specifico campo(sarà anche l'ora che non mi aiuta).Intendi dire che con Bench per 64bitrisulterebbe più lento?
  • avvelenato scrive:
    benchmark a 64bits
    Penso sia necessario standardizzare una ratifica universalmente accettata di benchmark a 64bits, così da valutare le prestanze di queste cpu.la x86-64, avendo puntatori e alcune istruzioni più lunghi, probabilmente comporterà un'incremento della dimensione del codice. Non so di quanto, voci mi hanno suggerito intorno al 15%, e se fosse così non sarebbe poi così significativo. Comunque, questo significa che i 512kbyte di cache su utilizzo 32bits valgono di più rispetto agli stessi su 64bits, o detto più chiaramente, l'arch. a 64 bits richiederebbe più cache.se poi questa cache in più richiesta in realtà è nell'ordine del 15%, penso non ci siano grossi "degradi" prestazionali, almeno fino a quando si sta sui 512kbites e oltre.il core Paris, che invece ne avrà 256, mi pare che avrà le istruzioni a 64bits disabilitate, quindi il problema non si pone ( forse AMD le vuole disabilitare per nascondere il fatto che quella cpu sui 64bits potrebbe risultare in alcune appz più lenta rispetto all'uso su 32??) avve che comunque adora le xp (per l'overclock sono sempre ottime, specie le M)
Chiudi i commenti