DVD multiformato anche da LG

La filiale tedesca di LG Electronics ha deciso di seguire la strada tracciata da Sony e introdurre un masterizzatore in grado di supportare i due formati concorrenti: DVD+R/RW e DVD-R/RW. Una tendenza che s'impone


Monaco (Germania) – Seguendo le orme di produttori come Sony e NEC, anche LG Electronics ha scelto di integrare, su di un solo masterizzatore di DVD, il supporto in scrittura ai due maggiori formati concorrenti: DVD-R/RW e DVD+R/RW.

Il drive, denominato GMA-4040B, supporta anche i formati DVD-RAM e CD-RW/R. Le velocità di scrittura offerte dal masterizzatore dipendono, come norma, dal tipo di formato: 3x per i DVD-RAM; 4x per i DVD-R e i DVD+R, 2x/4x per i DVD+RW, 2x per i DVD-RW, 24x per i CD-R e 16x per i CD-RW.

Il GMA-4040B, ultimo parto della joint venture Hitachi LG Data Storage (HLDS) formata lo scorso ottobre fra LG Electronics e Hitachi, verrà lanciato sul mercato europeo a partire dal prossimo giugno ad un prezzo ancora sconosciuto.

HLDS sostiene che i drive DVD multiformato sono la chiave di volta di questo mercato.

“Se fino a diversi mesi fa – ha spiegato il colosso – chi intendeva acquistare un masterizzatore di DVD riscrivibili doveva necessariamente scegliere fra lo standard DVD-R/RW (promosso dal DVD-Forum, NdR) e lo standard DVD+R/RW (creato da Sony, Philips, HP e Ricoh, NdR), oggi i masterizzatori multiformato offrono ai consumatori un prodotto che, sposando entrambi i formati, protegge l’investimento e garantisce una compatibilità totale”.

È proprio la battaglia fra i due standard, secondo gli analisti, che fino ad oggi ha creato confusione fra i consumatori e ha impedito al mercato dei DVD riscrivibili di decollare.

Un recente studio di mercato conferma come i drive multiformato contribuiranno in modo determinante ad accelerare la vendita di masterizzatori di DVD nei prossimi anni. La via, a questo punto, pare tracciata.

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

  • Anonimo scrive:
    MA LE MACRO E GLI SCRIPT .....
    SERVONO ????TROVO ASSURDO CHE CIRCOLINO DOCUMENTI POTENZIALMENTE DANNOSI .........TROVO ASSURDO che gli script e le macro presenti in undocumento possano accedere al file system .........SEMPLICEMENTE ASSURDO
    • Maik scrive:
      Re: MA LE MACRO E GLI SCRIPT .....
      Infatti. Come è semplicemente folle che lo si possa fare in una mail. Di nuovo, non è per trolleggiare, ma queste grandi novità sono state introdotte da Microsoft.
      • Anonimo scrive:
        Re: MA LE MACRO E GLI SCRIPT .....
        - Scritto da: Maik
        Infatti. Come è semplicemente folle che lo
        si possa fare in una mail. Di nuovo, non è
        per trolleggiare, ma queste grandi novità
        sono state introdotte da Microsoft.Esatto... le email devono essere di TESTO... e basta... poi al massimo se devi mandare dei grafici ,documenti , programmi a qualcuno li metti in un bel file .zip (cosi' tra l'altro eviti di spedire file .doc di 10 MB che compressi diventano 100K).Io odio la gente che mi spedisce file .DOC di 2MB con dentro tre righe di testo e un bel tema a fiorellini come sfondo.... bah.
        • Anonimo scrive:
          Re: MA LE MACRO E GLI SCRIPT .....
          siamo sempre lì, finchè c'è gente che manda doc allegati ad una mail html per dirti ciao come stai.......
  • Maik scrive:
    Problema comune a tutta l'industria?
    "La sfida nel fermare i virus nei documenti XML è un problema comune a tutta l'industria, e non è limitato solo a Microsoft Office 2003"Di grazia, Microsoft, quali altri formati di documento basati su XML sono vulnerabili ai virus? Quelli di StarOffice? Quelli di Open Office? Non mi risulta. Mi risulta, anzi, che gli unici documenti di word processor e spreadsheet vulnerabili ai macro virus siano proprio quelli progettati da Microsoft. Almeno non si generalizzi sostenendo che la colpa è di XML: la colpa è di chi progetta male i protocolli.
    • Anonimo scrive:
      Re: Problema comune a tutta l'industria?

      Di grazia, Microsoft, quali altri formati di
      documento basati su XML sono vulnerabili ai
      virus? Quelli di StarOffice? Quelli di Open
      Office? Non mi risulta. Mi risulta, anzi,
      che gli unici documenti di word processor e
      spreadsheet vulnerabili ai macro virus siano
      proprio quelli progettati da Microsoft.
      Almeno non si generalizzi sostenendo che la
      colpa è di XML: la colpa è di chi progetta
      male i protocolli.hello troll!il "protocollo" che crea il problema è appunto xml, che grazie alla sua elasticità utile per tantissime cose, nello specifico caso consente di mettere il codice dannoso in un qualunque punto del documento, che quindi dovrà essere scansionato tutto dall'antivirus, e non solo in alcune sue porzioni come ad es un binario. Sarà più semplice, grazie alla bontà del formato xml, fare la scansione di un intero xml che non di un intero file tipo un binario, ma meno che fare la scansione delle sole parti infettabili in un binario.Per tua maggiore erudizione già oo, e quindi staroffice, salvano in xml quindi se qualche virus writer con conoscenze di xml ha voglia può già creare problemi a chi usa questi prodotti, e non agli attuali office che salvano in formati proprietari M$.Non lo faranno mai dato che essendo questi prodotti poco usati (a proposito, io oo lo uso e tu?) la diffusione del virus sarebbe lenta e marginale (e i virus non si scrivono perchè non si diffondano...).Se MS Office cominciasse a salvare in xml, come nelle prossime versioni, invece sai quanti lo farebbero a caccia di 5 minutidi gloria? Il bello è che se M$ non introdurrà qualche artificio per rendere questi xml in qualche modo non standard gli stessi virus potrebbero benisimo andare su oo, star ecc... essendo appunto xml uno standard, non legato ad un prodotto!I prodotti M$ sono soggetti a macrovirus... certo, sono formati proprietari, hanno un linguaggio di script proprietario con cui ci si possono anche fare virus! Puoi rendere il linguaggio più sicuro, ma certo la potenza del linguaggio è proporzionale alle funzioni che gli dai, e un programmatore esperto può sfruttarle in tanti modi interessanti se vuole fare dei danni!A parte che questi formati e il loro linguaggio di scripting non c'entra nulla con l'xml, non sono certo gli unici programmi ad essere dotati di un linguaggio di scripting.La pericolosità dello stesso è, come ti dicevo, direttamente proporzionale alla potenza che vuoi dare a questo linguaggio e all'interesse che la piattaforma può offrire ai virus writer, a parte questo ogni linguaggio può essere reso più sicuro, questa è la scoperta dell'H2O calda!bye troll!
  • Anonimo scrive:
    speriamo lavorino di comune accordo
    sarebbe una buona cosa, per una volta ...
  • X-CASH scrive:
    Allora chi scrive antivirus e' pippa :)
    Scusate un po'... ma chiunque qui dentro sia un programmatore degno di questo nome sa quanto sia comodo e facile il parsing xml. tantopiu' che praticamente tutti i linguaggi di programmazione recenti hanno ottime librerie per farlo.Secondo me e' piu' facile individuare un macrovirus (perche' e' di questo che si parla) in un documento xml che e' aperto rispetto a trovarli in file binari dipendententi, tanto per dirne una, dalla versione del programma creatore.Io non vedo tutta sta preoccupazione.Inoltre io non concepisco nemmeno l'esistenza dei macrovirus... un sistema a macro cosi' aperte non ha senso di esistere (secondo me ovviamente). ma qui sono scelte di concept e io non sono molto a contatto con problematiche tipicamente office.
    • Anonimo scrive:
      Re: Allora chi scrive antivirus e' pippa :)

      Scusate un po'... ma chiunque qui dentro sia
      un programmatore degno di questo nome sa
      quanto sia comodo e facile il parsing xml.
      tantopiu' che praticamente tutti i linguaggi
      di programmazione recenti hanno ottime
      librerie per farlo.

      Secondo me e' piu' facile individuare un
      macrovirus (perche' e' di questo che si
      parla) in un documento xml che e' aperto
      rispetto a trovarli in file binari
      dipendententi, tanto per dirne una, dalla
      versione del programma creatore.

      Io non vedo tutta sta preoccupazione.

      Inoltre io non concepisco nemmeno
      l'esistenza dei macrovirus... un sistema a
      macro cosi' aperte non ha senso di esistere
      (secondo me ovviamente). ma qui sono scelte
      di concept e io non sono molto a contatto
      con problematiche tipicamente office.Il problema è che nei vecchi office le macro si trovavano ad un certo offset dall'inizio del file.Cioè se hai un Word da 10 MB, l'antivirus sapeva a colpo sicuro dove beccare la porzione da controllare, controllava quei pochi KB e chiudeva lo stream.Se i nuovi word sono salvati in XML in cui lo script può essere ovunque, allora l'antivirus deve scorrere _TUTTO_ il file. Indipendentemente dalla libreria XML usata. Cioè, nell'esempio sopra, tutti i 10 MB.Il che vuol dire che una scansione dell'HD potrebbe rallentare di decine di volte rispetto ad una volta.Il problema non è banale.
      • Maik scrive:
        Re: Allora chi scrive antivirus e' pippa :)

        Se i nuovi word sono salvati in XML in cui
        lo script può essere ovunque, allora
        l'antivirus deve scorrere _TUTTO_ il file.
        Indipendentemente dalla libreria XML usata.
        Cioè, nell'esempio sopra, tutti i 10 MB.Ma non è vero per niente. La classe IncrementalParser del modulo xml.sax.xmlreader di Python, per esempio, introdotta per il supporto a Sax 2.0, serve proprio ad accedere ad un singolo chunk della struttura XML senza dover leggere l'intero file. Aggiungi che Sax 2.0, essendo event based, non ha bisogno di creare in memoria l'intero struttura, come fa' DOM. Inoltre, essendo altamente strutturato, XML permette di individuare molto rapidamente il nodo che contiene una specifica informazione (nel caso citato, il codice macro).IMHO, i dubbi di X-Cash sono più che fondati
        • Anonimo scrive:
          Re: Allora chi scrive antivirus e' pippa :)
          per fare il parsing di un file è in ogni caso necessario passarlo tutto. Non puoi sapere a priori dove sta un certo tag. Il fatto che lo faccia una libreria esterna non cambia di una virgola il discorso, l'overhead è notevole per il sistema operativo.
          • Anonimo scrive:
            Re: Allora chi scrive antivirus e' pippa :)
            ovviamente intendo con un file xml attuale, non con elaborazioni successive e imho stupide come si dice nel proseguio del thread (puntatori e simili)
          • Maik scrive:
            Re: Allora chi scrive antivirus e' pippa :)
            - Scritto da: Anonimo
            per fare il parsing di un file è in ogni
            caso necessario passarlo tutto. Non puoi
            sapere a priori dove sta un certo tag. Il
            fatto che lo faccia una libreria esterna non
            cambia di una virgola il discorso,
            l'overhead è notevole per il sistema
            operativo.Leggiti la documentazione di IncrementalParser e scoprirai che non è vero. Naturalmente, per evitare di fare il parsing di tutti i nodi dovresti sapere fin dalle prime letture dove si trovano i nodi che ti interessano. Proprio per questo nell'articolo si afferma che i produttori di antivirus chiedono a Microsoft di memorizzare nei nodi iniziali la posizione del codice macro. Se fosse come dici tu, non si capirebbe perchè la soluzione proposta dai produttori di antivirus dovrebbe accelerare il processo di scansione
    • Anonimo scrive:
      Re: X-CASH ma che stai a di
      - Scritto da: X-CASH
      Scusate un po'... ma chiunque qui dentro sia
      un programmatore degno di questo nome sa
      quanto sia comodo e facile il parsing xml.
      tantopiu' che praticamente tutti i linguaggi
      di programmazione recenti hanno ottime
      librerie per farlo.
      Secondo me e' piu' facile individuare un
      macrovirus (perche' e' di questo che si
      parla) in un documento xml che e' aperto
      rispetto a trovarli in file binari1) in un file binario un virus può essere inserito solo in determinati punti, non e che un virus taglia a tre quarti un binario e si inserisce li.l'antivirus sa bene dove un codice virale può inserirsi (Il formato PE e ben definito e solo operando in un determinato modo ci si puo inserire un virus senza rendere il programma non più eseguibile), verifica la segnatura ed ecco fatto.invece in un file xml è possibile inserendo un cdate che contiene una macro in qualunque punto, quando il parsec incontra la macro la esegue.puoi ben capire che se io ti invio un xml di 10 MB ora come ora va scandito tutto.
      dipendententi, tanto per dirne una, dalla
      versione del programma creatore.

      Io non vedo tutta sta preoccupazione.vedila
      Inoltre io non concepisco nemmeno
      l'esistenza dei macrovirus... un sistema a
      macro cosi' aperte non ha senso di esistere
      (secondo me ovviamente). ma qui sono scelte
      di concept e io non sono molto a contatto
      con problematiche tipicamente office.appunto
      • X-CASH scrive:
        Re: X-CASH ma che stai a di
        - Scritto da: Anonimo

        Secondo me e' piu' facile individuare un

        macrovirus (perche' e' di questo che si

        parla) in un documento xml che e' aperto

        rispetto a trovarli in file binari

        1) in un file binario un virus può essere
        inserito solo in determinati punti, non e
        che un virus taglia a tre quarti un binario
        e si inserisce li.
        l'antivirus sa bene dove un codice virale
        può inserirsi (Il formato PE e ben definito
        e solo operando in un determinato modo ci si
        puo inserire un virus senza rendere il
        programma non più eseguibile), verifica la
        segnatura ed ecco fatto.Avresti ragione se non fosse che ti sei dimenticato di una cosa basilare. Stiamo parlando di documenti di Office. Non di eseguibili (hai nominato il PE :) ).Cmq si... in un file binario (anche documento) e' in una posizione ben precisa. ma bisogna cmq conoscerne il formato e leggerne l'header in quando file binari di documenti fatti bene sono quantomeno suddivisi in chunk.Io contesto la preoccupazione denunciata dall'articolo.Un file xml con un header fatto bene che delinea le posizioni di punti fondamentali puo' essere anche comodo e veloce per il programma stesso. Anche se potrebbe snaturare un po' il concetto di xml.Se si va a lavorare sui puntatori a punti del file in un xml e' un po' come tornare indietro.
        puoi ben capire che se io ti invio un xml di
        10 MB ora come ora va scandito tutto.Si. Questo si.
      • Giambo scrive:
        Re: X-CASH ma che stai a di
        - Scritto da: Anonimo
        invece in un file xml è possibile inserendo
        un cdate che contiene una macro in qualunque
        punto, quando il parsec incontra la macro la
        esegue.Fortunatamente quando il "parsec" incontrera' la macro, noi saremo gia' distanti 3.26 anni-luce :-DScusa, non ho resistito :-)
      • Anonimo scrive:
        Re: X-CASH ma che stai a di

        1) in un file binario un virus può essere
        inserito solo in determinati punti, non e
        che un virus taglia a tre quarti un binario
        e si inserisce li.Complimenti, sei un vero esperto. Dici che mettere un jump al codice virale all'inizio di una chiamata a funzione (riconoscibilissima per via dei pattern di compilazione) non funzionerebbe?
        • Anonimo scrive:
          Re: X-CASH ma che stai a di

          Complimenti, sei un vero esperto. Dici che
          mettere un jump al codice virale all'inizio
          di una chiamata a funzione
          (riconoscibilissima per via dei pattern di
          compilazione) non funzionerebbe?si vede che sei rimasto al tutorial "come realizzare virus per i file .com" , oggi creare un virus per un exe in formato PE e un po più complicato che mettere delle jmp (non jump) calcolate all'inizio del codice che puntano al virus.
  • Anonimo scrive:
    Tanto già è completamente insicuro...
    tanto vale arrendersi... oppure abbandonarlo!
    • Anonimo scrive:
      Re: Tanto già è completamente insicuro...
      la domanda è: perchè si parla a vanvera quando non si conosce niente, nulla di nulla, ne di XML ne di office ne di tante altre cose?XML è un linguaggio di modellazione ben formato semanticamente corretto e grammaticamente ben definito, la sicurezza è garantita dalla coerenza sintattica del linguaggio.Per quel che riguarda Office... una macro è una macro il codice che esegue operazioni è potenzialmente pericoloso ovunque.I programmi antivirus potrebbero trovare qualche algoritmo intelligente per scansionare dei documenti secondo standard (standard capito !? ) XML .Perchè questa sterile guerra di sterili cervelli?
      • Anonimo scrive:
        Re: Tanto già è completamente insicuro..
        - Scritto da: Anonimo
        la domanda è: perchè si parla a vanvera
        quando non si conosce niente, nulla di
        nulla, ne di XML ne di office ne di tante
        altre cose?
        XML è un linguaggio di modellazione ben
        formato semanticamente corretto e
        grammaticamente ben definito, la sicurezza è
        garantita dalla coerenza sintattica del
        linguaggio.Mi fanno ridere questi tentativi insulsi di associare le *parole* usate nella teoria ad una *presunta* applicazione della teoria.Qual'è la semantica di XML? Quella definita dall'interprete del caso. Se descrivi l'assembler in XML, e il tuo interprete produce un vero programma assembler e lo esegue, tanto per fare un esempio, mi spieghi perchè dovrei considerare la cosa più sicura di usare direttamente quel programma, che sicuro non è?Risposta: l'XML dà solo la sintassi.E piantiamola di dire cavolate...
  • Anonimo scrive:
    MAGARI!
    sarebbe splendido se la soluzione arrivasse direttamente dal W3C, il comitato "papà" di XML: il problema è che Sun spalleggia la "sua" idea di documenti XML "foraggiando" il comitato Oasis, e non credo abbia molta convenienza a permettere che questo avvenga... :-(
    • hoff scrive:
      Re: MAGARI!
      Le specifiche di Sun&c (che non esistono ancora) non hanno nulla a che vedere con le specifiche Xml del W3c, sono due cose completamente diverse. Prima di tutto, ovviamente, non ci sarà nessuna incompatibilità. Semplicemente, presumo, stenderanno delle linee guida per la stesura delle DTD utilizzate dai programmi da ufficio.
Chiudi i commenti