Sarà capitato qualche volta di avere a che fare con file “strani”, come ad esempio xpti.dat (che si trova nella cartella Data usata da FireFox), il cui nome non ci fornisce informazioni significative per comprendere il tipo di contenuto da essi veicolato.
In particolare, essendo ormai abituati a utilizzare il modello delle estensioni del nome del file per distinguere gli oggetti con cui abbiamo a che fare (.txt per i file di testo, .mp3 per le canzoni, .jpg per le immagini, ecc.), una genericissima e anonima estensione .dat non ci è affatto utile, se non per capire che ci troviamo di fronte a un formato “non standard” o comunque a noi ignoto.
Sarà colpa del “solito” formato “proprietario” che s’è inventata la software house di turno? Difficile crederlo considerato che quel xpti.dat proviene direttamente da “casa” Mozilla, azienda stabilmente legata al mondo open source (notoriamente avverso ai formati “proprietari”). Allora come stanno realmente le cose? Per capirlo dobbiamo fare un salto indietro, alle origini dell’informatica.
L’informatica è una scienza relativamente giovane, che nasce come branca della matematica, e il cui nome deriva dalla contrazione di due parole: informazione automatica. Si occupa, com’è facile intuire, di manipolare l’informazione in maniera “automatica” (o “meccanica” che dir si voglia), ricorrendo a strumenti “programmabili” (ove possibile).
Nel momento in cui si definisce il concetto di informazione trattata “automaticamente”, si pone il problema della sua rappresentazione. Senza il rischio di banalizzare il discorso o di perdere di generalità, possiamo assumere di manipolare informazioni rappresentabili “discretamente”, cioé essendo costituite da insiemi finiti di valori. Il cosidetto formato digitale (che si contrappone a quello analogico), per intenderci.
Il concetto di formato (“proprietario”) è conseguenza diretta, necessaria e immediata della suddetta rappresentazione. Per essere più chiari, nel momento in cui ho, ad esempio, bisogno di memorizzare numeri da 1 a 10.000, e prendo la decisione di utilizzare 2 byte (sfruttando la rappresentazione binaria), anziché 5 byte (uno per ogni cifra / carattere) o altro, ho già definito il formato di questi dati.
Questo processo di definizione riguarda tutte le informazioni manipolate dall’applicazione, per cui si arriva via via alla realizzazione di strutture più o meno complesse nelle quali esse risiedono.
Poiché la memoria dei calcolatori è generalmente volatile (allo spegnimento si perde qualunque informazione), o magari si ha la necessità di dover trasportare o duplicare questi dati, il passaggio successivo è quello della loro archiviazione. Per far questo si sfrutteranno le strutture già progettate e utilizzate, oppure se ne realizzeranno di nuove molte similari (avrebbe poco senso idearne di diverse, visto che sarebbe necessario poi un certo lavoro di adattamento).
Nasce così il formato “proprietario“, definito tale per un motivo molto semplice: perché è legato intrinsecamente all’applicazione per cui è stato realizzato. E’ un male? Non necessariamente. Anzi, quello di definire un formato per i dati manipolati abbiamo visto essere un problema contingente. Non se ne può, cioé, fare a meno.
Quindi una certa applicazione utilizzerà uno o più formati (possiamo anche togliere l’aggettivo “proprietario“, a questo punto, tenendo conto delle motivazioni che hanno portato alla sua creazione) per memorizzare le informazioni che manipola.
I problemi nascono, però, quando si ha l’esigenza di poter leggere e/o scrivere questi dati utilizzando un’applicazione diversa, oppure creandone un’altra. Si pone, cioé, il problema dell’accessibilità delle informazioni, che rappresenta forse (e magari correttamente) la fonte principale di tutte le diatribe incentrate su questi temi.
Diatribe che portano facilmente ad alzare la forca, specialmente quando si tratta di formati blasonati, diffusi, e riconducibili a multinazionali più o meno invise. A volte, però, le rimostranze risultano infondate o comunque non tengono conto della realtà dei fatti, basandosi più che altro sulle solite “voci” che col tempo sono degenerate nelle classiche leggende metropolitane, in un infinito circolo autoreferenziale.
Per fare un esempio, è il caso dei formati utilizzati dalla suite Office di Microsoft. Da tempo “si sa” che si tratta di formati “proprietari“, di cui la ben nota software house tiene chiuse nel cassetto le preziose informazioni necessarie alla “concorrenza” per sviluppare delle alternative.
Pochi, però, sono a conoscenza del fatto che da parecchi anni Microsoft mette liberamente a disposizione le specifiche di questi formati, con tanto di documentazione particolarmente ricca e dettagliata. Non sono nemmeno difficili da recuperare: è sufficiente una veloce (ma mirata, ovviamente) ricerca su qualche motore per ritrovarli fra i primi risultati la paginetta in questione.
Degno di nota è il fatto che risultano ben documentate tutte le versioni di questi formati. Qualcuno, però, potrebbe pensare che si tratti di materiale recente, che è stato messo in circolazione per tenere a bada enti quali l’antitrust. Sicuramente no, visto che esistevano almeno fino alla versione ’97 (un po’ di anni fa, cercando per la rete, li ho trovati e archiviati da qualche parte).
La guerra dei formati (o ai formati “proprietari“) necessita, dunque, d’esser riformulata in altri termini: quelli dell’accessibilità. Perché definire un formato “proprietario” è quanto di più naturale e legittimo possa fare un programmatore che ha l’esigenza di conservare le informazioni delle applicazioni che ha scritto. Con buona pace dei forcaioli che lo vorrebbero vedere “ciondolante”.
Interessante punto di vista! Potresti spendere qualche parola nel descrivere la differenza p. es. fra .xls, omologo OOXML e ODF in quanto ad apertura ed accessibilità delle specifiche?
E’ il punto di vista di un programmatore che ha a che fare con queste cose tutti i santi giorni. :D
Per quanto riguarda la domanda che poni, fra .xls e gli altri la differenza è che gli ultimi due sono standardizzati, mentre il primo no; mentre la differenza fra OOXML e ODF è che il primo ha dei mallopponi enormi che definiscono in maniera precisa le specifiche.
A parte questo, ci sono due considerazioni da fare, sempre dal punto di vista di un programmatore (o software house) che vuole scrivere filtri di import/esportazione dei dati per questi formati.
La prima è che, da questo punto di vista, non v’è nessuna differenza fra di loro, se non per la mera quantità di codice necessaria per arrivare allo scopo.
La seconda è che sui primi due potrebbero pendere dei brevetti per quanto riguarda alcuni algoritmi che servono per l’implementazione.
Ciò potrebbe portare a pensare di diffidare di loro. In realtà lo possiamo considerare un problema fino a un certo punto.
Infatti esistono infinite soluzioni a un determinato problema, per cui se un algoritmo non è utilizzabile perché brevettato, ce ne possiamo inventare un altro per risolverlo.
Un esempio è il formato ZIP: diffusissimo e su cui pendono alcuni brevetti della casa che l’ha creato (la Pkware, se la memoria non m’inganna), ma ciò non ha impedito di realizzare il progetto InfoZip che ne ha fornito un’implementazione completamente gratuita e sulla quale non pende alcun brevetto.
Personalmente ho delle difficoltà nel capire perché MS si sia buttata sul formato OOXML, e perché Sun abbia tirato fuori ODF con Star/OpenOffice, quando esisteva (era diffusissimo e “standard di fatto”) il formato di Office.
Al più sarebbe stato sufficiente standardizzare questo.
Il tutto chiaramente IMHO.
Gli aggettivi “proprietario” e “nativo” sono due parole differenti, con significati diversi.
Ingenuità, mancata informazione dell’autore, o che altro?
Basta leggere bene l’articolo per capirlo.
Ingenuità del lettore, o che altro?
beh però dire che MS mette a disposizione la documentazione per implementare dei proprio codec è eccessivo
qualcuno ha letto la documentazione di OOXML? fa pietà
con le informazioni fornite da MS non ci fai un tubo di utile e funzionante
del resto mi pare che OpenOffice e soci si affidino pesantemente al reverse engineering
Il lettore continua a non vedere altro che l’erronea sovrapposizione dei concetti di formato di archiviazione nativo ad un programma, e di formato proprietario, la cui definizione è soggetta ad un unico ente e che ne controlla le possibilità di implementazione, anche sul piano legale tramite, ad esempio, i monopoli concessi dallo stato sulle idee, più noti come brevetti sul software.
Davvero, non riesco a trovare dove venga indicata la differenza, ed al contrario, vedo solamente suggerita l’equazione formato proprietario == formato di archiviazione.
Aiuto. :)
@pabloski. Per l’OOXML, infatti, tirare fuori un filtro richiede parecchio lavoro.
Però se vai al link che ho postato nell’articolo e ti scarichi la documentazione su formato .doc (tanto per prenderne uno) noterai che è veramente molto ben fatta, e non serve alcun reverse engineering.
Non soltanto, ma Microsoft OOXML è a tutti gli effetti un formato proprietario, dal momento che già al tempo della discussione per l’assunzione a standard di Microsoft OOXML, il formato discusso non era quello implementato dai software venduti in licenza da Microsoft.
@Loris: l’articolo serve proprio a far riflettere sulla questione dei formati (in generale), e della tipica sovrapposizione dei due termini che hai citato.
Quando nasce un’applicazione, il formato utilizzato è nativo e proprietario. Chi ne ha in mano la definizione, se non il programmatore (o software house) che l’ha realizzata?
Il formato non è di dominio pubblico, ed è difficile arrivare a carpirne le informazioni se non andando a smanettare nel codice (sorgente, se disponibile, o binario, se non lo è).
Per quanto riguarda i brevetti che hai citato, l’esempio del formato Zip che ho fatto prima dimostra che non sono vincolanti per l’implementazione di un formato (significherebbe che non esiste nessun altro algoritmo utilizzabile, e da informatico mi sembra alquanto difficile).
E’, quindi, legato all’applicazione che l’ha utilizzato, come ho già detto.
Sarà poi l’autore a decidere quale strada imboccare, se quella del formato aperto o chiuso, e in entrambi i casi se su di esso penderanno dei brevetti oppure no.
Da qui l’esempio del formato Office, a torto ritenuto “proprietario”, cioé inaccessibile.
L’ambiguità, se la vuoi vedere, nasce dall’uso della parola “proprietario”, ma se leggi l’articolo sequenzialmente, le sfumature che assume sono ben definite.
Spero di essere stato chiaro. ;)
@Loris: l’OOXML è uno standard oppure no? Office 2007 è in grado di leggere & scrivere l’OOXML standardizzato, oppure no?
beh allora secondo il ragionamento fatto, che asserisce che microsoft documenta totalmente i propri lavori, quelli che partecipano ad openoffice (sun, ibm, novell, redhat solo per citare le piu’ grandi e partecipi) sono una manica di incompetenti che non è in grado di leggere una documentazione, se ancora oggi, hanno problemi con i file di excel….
oppure è piu’ plausibile dire, che puoi documentare quello che vuoi, ma se fai degli “arzigogoli” di codice, che mi impediscano di ottenere un risultato identico, con algoritmi diversi…
allora scusami, ma questo post è totalmente inutile.
i formati proprietari, per un uso che dovrebbe essere standard sono sbagliati punto.
perchè per scrivere un documento in excel, devo costringere chiunque lo legga a possedere una copia di office, altrimenti, rischia incompatibilita’?
sono cose che accadono, non me le sto inventando…
e allora sta documentazione microsoft, scusami, ma non serve a un benemerito…
se invece continui a pensare che la documentazione microsoft sia sufficiente, ti invito a dare la soluzione al team openoffice, sono sicuro che le aziende sopracitate saranno ben liete di premiarti in denaro per il lavoro svolto e per aver risolto i problemi su cui lavorano da quasi un decennio.
Se sono proprietari non possono essere standardizzati.
Per quanto riguarda Office, dai un’occhiata ai documenti del link. Ribadisco che li trovo molto ben fatti.
Tra l’altro esistono applicazioni diverse da Office e OpenOffice in grado di leggerli tranquillamente (c’è, ad esempio, una suite praticamente identica a Office che viene venduta in Cina: http://www.danwei.org/business_and_finance/kingsoft_attacks_microsoft_fre.php) : evidentemente qualcuno che s’è impegnato nell’implementazione c’è. ;)
beh devi anche mettere in conto che essendo cinese, non vigono neanche le stesse leggi sui brevetti, e che quindi magari clonano molti algoritmi, cosa che aziende internazionali, non possono permettersi… cioe’ stiamo parlando di 4 aziende enormemente competenti… ma basta parlare anche solo di sun e ibm, la cui seconda ha tra le sue fila, forse i ricercatori, e lo staff piu’ preparato al mondo, in svariati campi…
penso che se abbiano ancora qualche problema… non dipenda da loro, ma dai formati proprietari…
io sono d’accordo con te che un formato proprietario non puo’ essere standard, ma purtroppo a conti fatti lo e’…
allora, o si costringe microsoft ad aprire i formati, e standardizzarli.
o si costringe ALMENO gli uffici pubblici di tutto il mondo a usare formati aperti, STANDARD.
@caffeine
Concordo pienamente con quello che hai detto.
@caffeine. OOXML è un formato standard, al pari di ODT, dunque il problema non si pone. E non si pone nemmeno per il formato “classico” di Office, come ho già detto.
Su quest’ultimo ti ho portato la prova che un’anonima azienda cinese riesce nell’impresa di realizzare non soltanto un filtro per leggere e scriverne il formato, ma addirittura un clone spiccicato di Office (vedi le immagini).
E non è certo una questione di brevetti, perché almeno l’interfaccia non è brevettabile, e quella di Star/OpenOffice non è paragonabile a quella di Office.
Per gli algoritmi, se “pesano” i brevetti, vuoi forse dirmi che colossi del calibro di Sun e IBM non hanno gente capace di realizzarne di alternativi? Io non ci credo. Le ragioni saranno altre.
Nuovamente, formati proprietari sono tutti i formati di archiviazione, protocolli di comunicazione, etc…, le cui specifiche di implementazione vengono attivamente mantenute nascoste, al fine di creare una dipendenza degli utenti verso l’unico software sul mercato in grado di gestire tali formati.
http://it.wikipedia.org/wiki/Formato_proprietario
E non qualunque formato. Nel caso del software libero, ad esempio, il solo rilascio del programma rappresenta la definizione di un formato, e la documentazione per permettere ad altro software di operare sugli stessi dati.
Ai vari formati di file che vanno sotto il nome di Microsoft Office Open XML, è stato affibbiato l’epiteto di standard della defunta ISO. Ed i vari “AutoSpaceLikeWork95”, “RenderLikeWork98”, od i blob binari contenenti i vecchi formati binari non documentati, sono suffficienti a mostrarmi come per un formato proprietario, si possa effettivamente comprare l’etichetta di “standard” industriale raccomandato.
@Loris: il link che hai postato lo trovi in cima al mio articolo. Questo a dimostrazione che non mi è affatto nuovo ciò scrivi. ;)
Per quanto riguarda il software rilasciato sotto forma di sorgente, invece, mi permetto di dissentire: non basta la pubblicazione del codice per definire un formato.
Infatti chi m’impedisce di rilasciare i sorgenti di un’applicazione “libera”, ma scritti in maniera incomprensibile? Non c’è differenza col disassemblato di un codice binario, da questo punto di vista.
P.S. I vecchi formati binari sono, al contrario, molto ben documentati.
@ Cesare
Microsoft OOXML è un formato “standard” nei registri e nelle casse di ISO ed ECMA. Ma non al pari di ODT. :)
Standard non significa documentato. Non significa liberamente implementabile. Significa che qualcuno ha comprato l’etichetta per il nuovo barattolo da vendere.
Far uscire dalla stanza del consiglio ISO dei votanti coloro che non rappresentano Microsoft, Novell, ed i piccoli nomi fatti entrare ad hoc per la votazione, significa distruggere un ente di standardizzazione, e farne perdere ogni significato.
I formati proprietari esistono affinché il detentore dei diritti legali sial’unico dispensatore della artificiale scarsità/unicità delle informazioni e dei diritti legali di implementazione.
Che io sappia, non serve un miliardo di cittadini cinesi per implementare le funzioni di importazione e di rendering di un qualunque formato proprietario, sono sufficienti un pugno di buoni sviluppatori, ed i soldi per le specifiche di implementazione, rilasciati sotto Non Disclosure Agreement.
Tags: scarsità artificiale delle informazioni, lock in.
Scusami, mi sono fermato a leggere qui
“…Nasce così il formato “proprietario“, definito tale per un motivo molto semplice: perché è legato intrinsecamente all’applicazione per cui è stato realizzato…”
Dopo questa stronzata non potevo leggere oltre.
Da wipedia:
“…In informatica si definisce formato proprietario qualsiasi software le cui specifiche tecniche non siano di pubblico dominio…”
http://it.wikipedia.org/wiki/Formato_proprietario
loris, quali sarebebro dunque le informazioni che mancano per implementare i formati di Office?
quelli di sun e ibm dovrebbero saperlo bene, visto che è da un decennio che ci sbattono la testa.
hanno diffuso per caso qualche dichiarazione in cui dicono cosa manca, cosa non è documentato, in quale punto le specifiche non sono complete?
io voglio sapere in modo specifico in quli punti la documentazione di MS non è completa, altrimenti quei discorsi sono solo fuffa.
a me non risulta niente di tutto cio, per cui posso benissimo pensare che non hanno completato i plugin per office perche ci vuole molto tempo e denaro e visto che poi non ci guadagnano niente non hanno gli interessa farlo.
chi li spinge a spendere milioni di dollari per creare i plugin per office completi al 100% se tanto poi nessuno glielo paga openoffice?
@Loris: a me risulta che OpenOffice sia in grado di leggere OOXML. Dunque MS non ha il monopolio della sua implementazione.
Inoltre, ribadisco che i documenti con le specifiche ci sono sia per i vecchi che per i nuovi formati.
@Lorem: quel link è riportato in cima al mio articolo. Evidentemente hai qualche difficoltà di lettura.
Tra l’altro, cosa non ti è chiaro di questo:
“è legato intrinsecamente all’applicazione per cui è stato realizzato”
?
Per caso sei capace di sviluppare un’altra applicazione che è in grado di leggere e/o scrivere i file generati da un’altra che non ha mai rilasciato alcuna specifica (in particolare, si trova nelle condizioni descritte nell’articolo)?
Per il resto, al prossimo epitito o mancanza di rispetto il tuo messaggio verrà cancellato: si può benissimo discutere senza offendere, se ne sei capace.
È@ Cesare
Dissento dal tuo dissentire. :)
Il codice di un software non può lasciar dubbio di interpretazione, poiché deve essere interpretato in modo univoco da un interprete, il compilatore, secondo un linguaggio definito.
Il codice di un software è la sua miglior documentazione, per un “addetto ai lavori”. La redazione di documentazione è utile come astrazione a più alto livello della logica impiegata, ma la redazione di codice modulare, scritto seguendo le basi intuitive della disciplina di sviluppo, sono una mappa senza vie dubbie o strade sovrapposte.
Se volessi mantenere “segreto” un formato di archiviazione, di certo non vorresti rilasciare il tuo software come libero. La logica occultata durerebbe il tempo di una notte, e di un pacchetto di biscotti al cioccolato. :)
@Loris: http://www.de.ioccc.org/main.html prova a decodificare il funzionamento di queste applicazioni.
Il sorgente c’è, quindi non dovresti avere difficoltà. ;)
wikipedia dice che il “formato proprietario” è il software senza specifiche di dominio pubblico ? -.-
sapevo che wikipedia è scadente.. ma non credevo fino a questo punto..
un formato proprietario non puo’ essere un software ma semmai il sistema che il software utilizza per archiviare i suoi dati.. un software senza specifiche di dominio pubblico semmai è closed source.. non un formato proprietario..
buone vecchie enciclopedie cartacee a PAGAMENTO.. altro che wikipedia.. pfui..
p.s. sono contento di usare Office 2007 :-D dopo aver provato openoffice e affini ho aggiornato office ’97 a office 2007 magna cum gaude :-D
@Lorem: ** COMMENTO MODERATO ** T’avevo avvertito.
Per il resto ti consiglio di leggere meglio l’articolo e il contesto di quella frase. E concordo col commento di Notty.
@ Cesare
Il caro vecchio C obfuscation contest. :)
Erroneamente, viene sempre tirato in ballo come dimostrazione di una possibile implementazione di software di cui sia impossibile risalire alla logica utilizzata.
Ovviamente, è cosa buona solo per due risate con gli amici, perché non è software mantenibile in versioni successive, non è possibile implementare un programma sufficientemente complesso (nozione relativa, ma al 2009 il comune software costruisce su così tante componenti dateci dai giganti del passato, da essere enormemente complesso), e non fornisce alcun occultamento della logica utilizzata. Inoltre, è fortemente non ottimizzato, il che ne rende poco appetibile lo sviluppo da parte degli ipotetici sviluppatori, e l’utilizzo da parte di un eventuale, malcapitato, utente.
Se avessi mai provato, prendi uno di quei sorgenti del contest, passali per un preprocessore C, e vedrai il tutto prendere forma. Filtra l’output con un formattatore automatico di sorgenti, apri il risultato in un editor con evidenziazione della sintassi, e magicamente il linguaggio C prende nuovamente forma. Individua i nomi delle variabili, esegui opportune sostituzioni con l’uso di espressioni regolari, e puoi perfino leggere il papiro.
Codice leggibile, debugger con accesso al sorgente, aree di memoria, una lunga, oscura e silenziosa notte, ed i biscotti al cioccolato fatti in casa. Indispensabili. :)
Se invece di un esempio di ASCII art, vuoi un miglior esempio di tentativo di occultamento della logica del codice, ti consiglio di vedere come NVIDIA ha fregato tutti i suoi utenti offuscando il driver libero per Xorg per le sue schede:
Gli sviluppatori di Xorg prendono le distanze dal comportamento di NVIDIA:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/README.RIVATNT.diff?r1=1.1.2.2&r2=1.1.2.3&hideattic=0&only_with_tag=xf-3_3_3
Un gran bel commit da parte di NVIDIA:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv3driver.c.diff?r1=1.1.2.5&r2=1.1.2.6&hideattic=0&only_with_tag=xf-3_3_3
@Loris: non mi sembra di aver detto che da quei sorgenti offuscati sia impossibile risalire al loro funzionamento. Anche dal codice offuscato di nVidia di cui hai postato i link si possono ricavare le informazioni su come lavora.
Però serve lavoro. Parecchio più lavoro rispetto a un sorgente scritto “in altra maniera”.
Cosa succederebbe se nVidia non fornisse alcun sorgente ma esclusivamente codice binario? Secondo te sarebbe impossibile risalirne al funzionamento?
Perché il nocciolo della questione sta tutto qui, visto che hai affermato che è sufficiente avere sotto mano il sorgente di un’applicazione per definire il formato dei dati che elabora.
Per te è il sorgente la discriminante, e io ho eccellenti ragioni per non essere d’accordo. Ragioni a cui non è difficile arrivare riflettendo sulle domande che ho posto qui sopra. ;)
@ Cesare
Scusami, con il precedente post:
“@Loris: http://www.de.ioccc.org/main.html prova a decodificare il funzionamento di queste applicazioni.
Il sorgente c’è, quindi non dovresti avere difficoltà. ;)”
mi era sembrato volessi suggerire che l’impresa fosse soltanto per stomaci forti, se non impossibile.
Già, la differenza sostanziale è che con quel commit, NVIDIA ha fatto divenire quel driver un software proprietario (non sono l’unico a pensarlo, ma anche molti Debian developer: opinioni personali, punti di vista), poiché dal 2003 è l’unica in grado di apportare modifiche ad un software derivato dall’offuscamento di un driver interno, tramite macro e valori esadecimali hardcoded nel driver.
Il significato di quei valori è ignoto (…ma il progetto Nouveau…), perché in questo caso il driver non è un filtro per aprire/salvare un formato di archiviazione dati, ma una logica di programmazione di un componente hardware, una macchina senza le etichette sulle leve da muovere.
È un’altra cosa, rispetto il trattamento di dati archiviati.
Parlando di formati di archiviazione, e tornando alla distinzione nativo/proprietario, è sempre possibile (come tu stesso affermi) risalire al funzionamento della logica utilizzata dati i sorgenti del programma che effettua l’accesso alle informazioni.
Un software proprietario, invece, obbliga al retro-engineering, all’analisi passo per passo di quanto accade, ed è limitato all’eventualità dei diversi casi presentabili.
Molto spesso, per quanto sia possibile, semplicemente non ne vale la pena.
Il discriminante per la questione libertà implementativa di un formato, a mio vedere, non è il sorgente (per quanto la fiducia per l’accesso ai miei dati sia cosa di fondamentale importanza), quanto qualunque forma di documentazione, quale il sorgente ne è esempio massimo. Perché funziona, ed è l’implementazione esatta della stessa specifica, cosa che può non accadere con la documentazione. (La documentazione spesso può persino risultare ambigua, e per quanto possa sembrare un controsenso, può indurre in errore. Diciamo che avere entrambe non sarebbe male. :D Nel caso di Open Document Format, infatti, vi era una implementazione già da molto tempo prima della discussione della documentazione in ISO).
Ti ringrazio molto della discussione, al prossimo post.
Volevo semplicemente evidenziare che la differenza fra un sorgente e un eseguibile dal punto di vista del funzionamento dell’applicazione è esclusivamente dettato dal tempo (e le risorse, in generale) necessario per arrivarci.
Non ho fatto un preciso esempio prima, perché m’interessava approfondire la discussione, che poteva essere interessante proprio per l’articolo che ho scritto.
L’esempio era quello del linguaggio macchina, che può benissimo essere utilizzato per scrivere una qualunque applicazione. E’ un linguaggio, per cui un sorgente che ne fa uso per definizione dovrebbe permettere di definire il formato dei dati che manipola. Solo che un sorgente in linguaggio macchina non ha praticamente differenze con un eseguibile, e non è necessario alcun reverse-engineering.
In una frase, il linguaggio macchina rappresenta il “punto di giunzione” fra sorgente ed eseguibile, e di fatto ne annichilisce le differenze.
Similmente, c’è un sottile confine che separa il software dall’hardware, ma qui entriamo nel campo della teoria della computabilità che riduce tutto a funzioni e numeri (e teoremi un po’ ostici e controintuitivi), ma il discorso diventerebbe troppo pesante.
Comunque nel caso dei driver nVidia rimane possibile risalire sia al loro funzionamento, che a quello dell’hardware con cui s’interfacciano. Anche qui, è soltanto una questione di “costi”. ;)
Grazie anche a te per la discussione. :)
Come al solito tutto porta alla grande guerra microsoft-è-la-migliore contro microsoft-fa-schifo…
Quello che ho letto nell’articolo… mi ha confuso!!!
A mio parere c’è una bella differenza tra un file come quello dell’esempio xpti.dat di firefox e un file come un documento.
tutto stà nello scopo per cui è stato creato un programma: se un programma deve produrre documenti di testo, piuttosto che presentazioni, considererei ottimo che quelle stesse presentazioni possano essere aperte da chiunque anche con altri programmi, quindi che il metodo di salvataggio sia noto.
Quando invece al programma serve di salvare i dati, per esempio sullo stato dell’appliccativo stesso ad esempio quando c’è un crash in firefox lo si può ripristinare con le pagine che si stavano visitando, questo indica che saranno salvate da qualche parte. questo tipo di salvataggio credo possa essere fatto tranquillamente in un file di cui non sono note le specifiche, ma solo perchè il contenuto non è rilevante per nessun altro eccetto firefox stesso.
credo che questa distinzione che non ho trovato nell’articolo sia cruciale.
Per quanto riguarda la compatibilità con altri editor di testo… non credo proprio microsoft abbia fornito tutte le speifiche esatte al 100%, dopotutto microsoft ha sempre fatto così, dal web, ai formati multimediali: fa in modo di renderli compatibili, ma non al 100%, in modo da avere sempre il prodotto migliore per quel formato che ha creato MS stessa.
Non c’è nessuna guerra. Si è discusso di formati proprietari e non, e la citazione di Microsoft è funzionale allo scopo. Avrei potuto parlare di Adobe e del PDF, e non sarebbe cambiato nulla.
Mi spiace che l’articolo non sia chiaro. Ne prendo atto e cercherò di farne tesoro per il futuro.
Il contenuto che tu pensi sia rilevante esclusivamente per FireFox, potrebbe invece essere di carattere più generale.
Se esistesse un formato “standard” per i salvataggi delle pagine a seguito di crash, qualunque browser potrebbe implementarlo e sfruttarlo, ad esempio, per riaprirle con Opera.
L’articolo non fa le distinzioni che hai fatto tu, perché non ha la pretesa di andare ad analizzare il singolo caso specifico, ma affronta un discorso più generale (nel quale, comunque, ci rientrano entrambi gli esempi che hai fatto, come vedi).
Sulle specifiche fornite da MS, se hai prove che ne abbia nascosto qualche dettaglio, non hai che da fornirle.
Io ho riportato esempi di applicazioni in grado di leggere tranquillamente sia il vecchio che il nuovo formato di Office. Dunque qualcuno ha in mano tutte le specifiche per poterlo fare, e non si tratta esclusivamente di MS.
Ti faccio notare, infine, che i documenti di testo che hai citato all’inizio del tuo messaggio non sono tutti uguali. Più precisamente, non tutti i s.o. e/o applicazioni rispettano gli standard.
Lo standard ASCII prevede, infatti, per andare alla prima colonna della successiva riga (in parole povere, il classico “a capo”) di un file di testo l’utilizzo di due caratteri, con codice 13 (CR) e 10 (LF).
DOS e Windows utilizzano correttamente entrambi i caratteri.
I s.o. Unix-like eliminano il primo, tranne OS X che elimina il secondo.
Quindi possiamo dire che questi ultimi sono fuori standard, mentre i primi si attengono rigorosamente a esso.
Sembra strano, vero? Eppure è così, standard ASCII alla mano. ;)
Se non ricordo male, al tempo del rilascio della doc ci si lamentava che i formati erano si documentati, ma non si poteva dire lo stesso per le tecniche di visualizzazione!!
in pratica puoi accedere ai dati contenuti nel file ma non sai come visualizzarli!!!!!
Però qualcuno ci riesce (vedi sopra). Tranne chi, appunto, si lamenta… ;)
Avresti potuto parlare di Adobe e PDF, al posto di MS, solo che PDF è un formato aperto e standardizzato, quindi non sarebbe per nulla la stessa cosa.
Poi non si capisce come mai dovresti fare l’esempio di un file di impostazioni di firefox come formato chiuso. C’è il sorgente che lo legge e sopra ci sono impostazioni che riguardano quel programma, mica dati che devono essere scambiati.
Per il resto hai ragione, l’importante è l’accessibilità dei dati. Per questo motivo i formati office vecchi ed OOXML sono comunque da considerarsi più sul chiuso: sono legati a MS e non si ha la garanzia che in futuro funzionino con altri editor.
Nonostante tutta la documentazione, ci sono file che funzionano solo su MSOffice.
Nonostante l’approvazione da parte di ISO di OOXML, il grosso della gente non lo riesce a vedere e, di fatto, neanche MS implementa quello standard nei suoi prodotti. Oltretutto lo standard ha dei grossi problemi ed è stato approvato a suon di pressioni, in maniera molto dubbia.
Alla fin fine se vuoi dei documenti che non siano legati ad un programma o ad una piattaforma, ti conviene usare openoffice ed eventualmente salvare anche in formati office vecchi.
Ti risulta male: il PDF è stato un formato blindatissimo da Adobe fino a poco tempo fa, quando ha finalmente deciso di farlo diventare uno standard rilasciando le proprietà intellettuali che deteneva. Cosa che non si può dire, invece, per Office, visto che chiunque poteva implementare filtri per i suoi formati.
L’esempio del file di FireFox mi è servito per introdurre il discorso. Se leggi l’articolo sequenzialmente capisci il perché l’abbia tirato in ballo.
Non esiste la definizione di formato “più sul chiuso”. Un formato o è aperto o è chiuso. Quelli di Office, vecchi e nuovi, sono aperti, di cui uno è stato standardizzato (tant’è che OOXML è utilizzabile anche da OpenOffice).
In ogni caso, visto che anche il vecchio formato è disponibile ed è aperto, considerato che è anche il più diffuso, rappresenta la scelta migliore per chi vuol realizzare documenti che siano accessibili da chiunque senza sbattimenti di testa.
Hai ragione, e non conosco bene i formati MS office da poter dire che non sono accurati al 100%, mi ero basato solo su esperienze varie che ho avuto con microsoft, per di più conosco moooolto bene come lavora SUN, e non escluderei che il suo prodotto non sia ben rifinito appositamente per vendere assistenza, un po’ come fa con parecchi programmi per sistemisti (IDM, ecc.).
tornando all’articolo, non è che non sia chiaro, però mi aspettavo di trovare una differenza tra i file che costituiscono il “business value” dell’applicazione e i file di supporto all’applicazione stessa.
Quello di firefox era solo un esempio.
E’ il business value cioè il prodotto che da valore al produttore a mio parere la cosa che deve essere portabile, il resto non è importante. nel caso di word è il .doc nel caso di winrar è il .rar. tutto il resto non è importante perchè se io compro winrar lo compro per creare file .rar.
Non standardizzare il business value è un po’ come se la fiat iniziasse a produrre auto che per legge non possono mettersi in strada, allora iniziasse a costruire una rete privata di strade su cui possono circolare solo fiat.
oops… hurtle = Roberto
Ma qui non siamo nelle stesse condizioni: Office è un formato utilizzabile da chiunque, e non paragonabile a WinRAR, ad esempio, perché quest’ultimo, che io sappia, ha rilasciato come open source & documentazione soltanto le informazioni necessarie alla decompressione dei file, guardandosi bene dal fornire quelle utili per realizzare prodotti concorrenti in grado anche di comprimere.
D’altra parte l’esigenza di realizzare applicazioni di tipo “office” non è da MS, e ogni produttore che s’è cimentato ha, giustamente (vedi articolo, appunto), tirato fuori il proprio formato.
Per quanto mi riguarda rimane esclusivamente un problema di accessibilità, come ho sottolineato più volte.
Qualcuno mi risponde al post 20?
Avete detto che la documentazione fornita da MS non è completa: avete delle prove per affermarlo?
In quali punti non sono complete, quali sono le informazioni che mancano?
Visto che parlate con tanta saccenza mi immagino che ve le siete lette e studiate molto bene, o parlavate solo per sentito dire?
ps: dire che se Sun non è riuscita a implementarle allora non sono complete non è valido, ci possono essere mille altri motivi.
@brion per favore, manteniamo moderati i toni. Possiamo benissimo esprimere le nostre idee anche senza eccedere con le parole.
Il problema delle specifiche dei .doc .xls .ppt date da Microsoft e’ la _licenza_ con la quale queste informazioni vengono pubblicate
http://www.microsoft.com/interop/osp/default.mspx
Io di una cosa cosi’ non mi fido
Qual è la differenza con Adobe che ha rinunciato a perseguire chi realizza applicazioni in grado di scrivere documenti PDF (di cui detiene brevetti e proprietà intellettuali)?
articolo interessante, ma c’e’ da dire che il DAT e’ il formato proprietario per antonomasia.
vuol dire dati di quella specifica applicazione, e inutili per qualsiasi altra, dati di cui non c’e’ in alcuni modo l’interesse anche teorico ad essere esportati in altre applicazioni.
ad esempio io mettevo come DAT file di applicazioni fatte da me, che buttavano su quei file dei dati temporanei di quella sessione di lavoro.
che poi esista della gente che per dei dati che devono essere portati su altre applicazioni, usi l’estensione DAT e’ un altro discorso.
I formati open sono una bufala.
Io sono totalmente d’accodo con questo articolo:
http://aovestdipaperino.com/posts/open-document-mess.aspx
[…] In precedenza abbiamo trattato l’argomento dei formati cosidetti “proprietari”, che però non ha esaurito il “filone”, lasciando aperte alcune questioni. In particolare, non era lo scopo e non era stato trattato il tema della legittimità o meno alla fruizione di un particolare contenuto. Perché non tutti i contenuti sono, appunti, utilizzabili… […]
Io uso regolarmente Office e OpenOffice. Mi sono accorto che alcuni documenti di Office non possono essere letti in modo corretto da OpenOffice perché quest’ultimo manca di una o più funzionalità che invece Office ha.
Se si apre un documento con OpenOffice di una certa complessità il testo si riesce anche leggere tutto ma magari è mal formattato, proprio perché OpenOffice non riesce a rederizzare tutto.
E’ un problema dovuto al filtro di importazione di OpenOffice, perché, come dicevo prima, le specifiche del formato Office sono disponibili da tempo e ben documentate.
Credo di essermi spiegato male, lo faccio con un esempio
Supponiamo che io scriva un foglio Excel e in una casella uso una funzione che Calc non ha, se poi questo foglio lo apro appunto con Calc OpenOffice legge il nome della funzione ma non è in grado di eseguirla
Lo stesso vale con Word e Writer, in Word le immagini si possono mettere come sfondo e farle uscire dal bordo del documento, se ne vede solo un pezzo, mentre in Writer no. Quindi se faccio un documento Word in cui metto una immagine che trasborda e poi lo apro con Writer quest’ultimo riesce la leggere l’immagine, quindi il file lo ha letto giusto, ma non me la posiziona corretamente.
Rimane un problema di OpenOffice, perché le specifiche per il formato di Excel ci sono e, quindi, è possibile scrivere un filtro e adattare OO in modo da poter caricare e manipolare correttamente i file di questo tipo.
Se non ci fossero le specifiche, la questione sarebbe diversa ovviamente, ma non è questo il caso.