OnlyOffice: l'alternativa open source e on premise a Microsoft 365

[biffuz]

Originariamente inviato da cdimauro

Se non capisci è un problema tuo, a questo punto: ho scritto quali siano le problematiche con quei due linguaggi, e usandoli assieme su un prodotto come quello hanno realizzato un pastrocchio.
--
Io sul tecnico ci sono già entrato e ho illustrato le problematiche note dei linguaggi citati.

A dire il vero non hai dimostrato un bel niente, e sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi", ma vabbé.

Mai sentito. E immagino che tu non abbia alcuna fonte, visto che successivamente ne hai riportato soltanto una che afferma che usino C++ per Office.
--
Spero ti renda conto che ciò deponga a sfavore di ciò che avevi scritto prima, che ti riporto per comodità:
"Il fatto che gli engine di Office sono scritti in assembly è riportato in molti articoli, anche scritti da dirigenti MS, che leggo sin dagli anni '90. Per questo ci mettono una vita a portarlo sulle nuove architetture."

--
A giudicare dalla storia di Office, e dei porting che ne sono fatti nel tempo, Microsoft non ha proprio avuto problemi con architetture diverse.
--
Il che lascia pensare che l'uso dell'assembly fosse decisamente ridotto.
--
Quando porterai fonti su Office scritto in assembly ne riparliamo.
--
Il che, ancora una volta, proverebbe che Office NON sia affatto difficile da portare su architetture diverse, come falsamente avevi attestato prima.

Mi secca ammetterlo ma non trovo fonti online, dopo ben quindici minuti di ricerche. Tutto quello che posso dire è che leggevo parecchie riviste negli anni '90/'00 e questo fatto era riportato più volte. Visto che non sei il mio capo o un mio cliente, e questo non è uno studio scientifico o un articolo di giornale, e nemmeno c'è rischio che su questa affermazione nasca un culto come quello della terra piatta, io mi fermo qui.

A voler essere pignoli, nemmeno tu hai riportato alcuna fonte che spiegasse in quale linguaggio è scritto Office, hai solo dato per scontato che non fosse assembly.

Con ciò è evidente che NON usi Visual Studio e quindi lo sconosci del tutto. Soprattutto è evidente che non solo non ti sia preso la briga di leggere una paginetta che già all'inizio avrebbe dovuto farti capire come stiano le cose, ma neppure leggere l'estratto che avevo riportato per comodità.

Infatti quella parte del manuale riguarda, sì, l'inclusione di codice assembly nel codice C/C++, ma ciò è possibile SOLTANTO per IA-32/x86:

"The following topics explain how to use the Visual C/C++ inline assembler with x86 processors"

e NON per x64 e ARM, come avevo già riportato:

"Inline assembly is not supported on the ARM and x64 processors."

Per la serie: non ho la minima idea di quello di cui parlando, ma lo faccio lo stesso.

Se lo dici tu...

http://www.biffuz.it/tmp/Immagine.png (non si carica inline perché non ho https)

Sicuro di aver capito di cosa parla la paginetta che mi hai linkato?

Potrei farti un esempio più completo, in cui chiamo codice assembly da C++ e viceversa, ma ho già sprecato abbastanza pausa pranzo. Se vuoi approfondire sentiti libero di cercare ulteriori fonti online.

Quello che riporti non è un problema dei formati di Office, visto che tu stesso riporti problematiche simili con altre applicazioni.

E aggiungo che si tratta di una cosa perfettamente naturale e comune per qualunque applicazione: quando vengono aggiunge nuove funzionalità a un formato, è ovvio che ci saranno problemi con le precedenti versioni dell'applicazione.

Veramente OpenDocument E' uno standard ISO:
"OpenDocument Format (or ODF for short) is the worlds leading document standard as maintained by the Organization for the Advancement of Structured Information Standards (OASIS), and was first adopted as an international standard in 2005 by ISO/IEC JTC1 SC34."

FUD e campagna contro, come al solito quando si parla di Microsoft.

Infatti, come puoi leggere dal secondo link, l'approvazione è fallita la prima volta, e OpenXML è stato approvato soltanto dopo. Peraltro con la Norvegia a favore, quando prima s'era scagliata duramente contro.

Mi pare ovvio che faccia i suoi interessi. OpenXML è un formato che si adatta perfettamente all'implementazione di Office, per cui è più facile da implementare e mantenere per Microsoft.

Standardization of Office Open XML:
"he Office Open XML file formats were standardised between December 2006 and November 2008, first by the Ecma International consortium (where they became ECMA-376), and subsequently, after a contentious standardization process, by the ISO/IEC's Joint Technical Committee 1 (where they became ISO/IEC 29500:2008)."

Ancora una volta, non hai la minima idea di ciò di cui parli.

Direi proprio di sì, e l'ho pure provato.

Francamente hai provato che leggi solo le parti che ti interessano dei link che tu stesso riporti.

[cavaliereombra]

Originariamente inviato da andy45

Si, è solo in abbonamento, quelli aziendali sono al mese, ma puoi fare solo sottoscrizioni annuali mi sembra, quelli domestici possono essere anche solo mensili, ma hanno delle buone offerte per l'abbonamento annuale.

Diciamo anche una cosa: prendere il 365 conviene se si fa la versione "Family" (ex "Home") e si divide la spesa con altri, fino a un massimo di 6 persone (ciascuna delle quali può poi usare la licenza su più dispositivi, tra PC, tablet e smartphone).

In famiglia ne abbiamo una e ogni anno acquisto un codice di rinnovo su Amazon (ultima volta speso 59,99 €); dividendo la spesa per 6 diventano nemmeno 10 € all'anno a testa.

https://www.amazon.it/Microsoft-Offi...dDbGljaz10cnVl

Questo anche per dire quanto poco costa Office se si usa un po' la testa.

[cdimauro]

Originariamente inviato da biffuz

A dire il vero non hai dimostrato un bel niente, e sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi", ma vabbé.

Direi proprio di sì. C# è più produttivo, più veloce, e mediamente molto più parco di risorse rispetto a Java, tanto per fare un esempio di due linguaggi/piattaforme similari.

Ecco qualche benchmark.

Mi secca ammetterlo ma non trovo fonti online, dopo ben quindici minuti di ricerche. Tutto quello che posso dire è che leggevo parecchie riviste negli anni '90/'00 e questo fatto era riportato più volte. Visto che non sei il mio capo o un mio cliente, e questo non è uno studio scientifico o un articolo di giornale, e nemmeno c'è rischio che su questa affermazione nasca un culto come quello della terra piatta, io mi fermo qui.

Anch'io leggevo riviste dell'epoca nonché BBS, e non ho mai letto roba del genere.

A voler essere pignoli, nemmeno tu hai riportato alcuna fonte che spiegasse in quale linguaggio è scritto Office,

Non ne avevo bisogno: non ho mai proposto tesi del genere, e dunque non avevo alcun onere da sostenere.

hai solo dato per scontato che non fosse assembly.

Continui ad avere problemi di lettura: mai detto nulla del genere.

Ecco qui ciò che avevo scritto in merito: "Dubito fortemente che abbiano mantenuto il core in assembly, se non eventualmente per piccole sezioni critiche per IA-32/x86"

Che è ben diverso da quanto vorresti appiopparmi.

Se lo dici tu...

http://www.biffuz.it/tmp/Immagine.png (non si carica inline perché non ho https)

Sicuro di aver capito di cosa parla la paginetta che mi hai linkato?

Continui ad avere problemi di lettura. Ecco cosa riporta quella paginetta:

"Inline Assembler
[...]
You can use the inline assembler to embed assembly-language instructions directly in your C and C++ source programs without extra assembly and link steps. The inline assembler is built into the compiler, so you don't need a separate assembler such as the Microsoft Macro Assembler (MASM)."

Potrei farti un esempio più completo, in cui chiamo codice assembly da C++ e viceversa, ma ho già sprecato abbastanza pausa pranzo. Se vuoi approfondire sentiti libero di cercare ulteriori fonti online.

Non ne ho bisogno, grazie. Il tuo esempio dimostra che devi ricorrere a un assembler esterno, come riporta la suddetta documentazione Microsoft. Cosa ovvia, e che peraltro puoi fare anche con linguaggi di programmazione diversi, ma è un'altra cosa rispetto a poter avere assembly inserito direttamente nel codice C/C++, che è di gran lunga più comodo, semplice, e non richiede salti mortali quando hai a che fare con applicazioni complesse, soprattutto se OOP.

Francamente hai provato che leggi solo le parti che ti interessano dei link che tu stesso riporti.

Cercare di cambiare discorso è perfettamente inutile. Avevi detto questo:
"I problemi dei formati di Office sono stranoti, non capisco perché insisti a dire che sono aperti e documentati"
che è palesemente falso, come ho dimostrato.

[biffuz]

Originariamente inviato da cdimauro

Direi proprio di sì. C# è più produttivo, più veloce, e mediamente molto più parco di risorse rispetto a Java, tanto per fare un esempio di due linguaggi/piattaforme similari.

Ma cosa c'entra C# adesso?
Java e C# a mio parere sono talmente simili che la produttività è questione di gusti e abitudini, e gli IDE aiutano molto, ma meglio che non scendo nei dettagli prima che mi chiedi le prove.

Non ne avevo bisogno: non ho mai proposto tesi del genere, e dunque non avevo alcun onere da sostenere.

Continui ad avere problemi di lettura: mai detto nulla del genere.

Ecco qui ciò che avevo scritto in merito: "Dubito fortemente che abbiano mantenuto il core in assembly, se non eventualmente per piccole sezioni critiche per IA-32/x86"

Che è ben diverso da quanto vorresti appiopparmi.

Credo che tu abbia ragione, d'ora in poi penso che inizierò ogni frase con "dubito fortemente", "sono ragionevolmente sicuro", "a mio modesto parere" o locuzioni simili, così se qualcuno mi smentisce posso sempre uscirne con "la mia non era un'affermazione, stavo solo esponendo un'opinione".
Mi pare anche che molti politici con gran seguito facciano la stessa identica cosa, dopotutto...

Continui ad avere problemi di lettura. Ecco cosa riporta quella paginetta:

"Inline Assembler
[...]
You can use the inline assembler to embed assembly-language instructions directly in your C and C++ source programs without extra assembly and link steps. The inline assembler is built into the compiler, so you don't need a separate assembler such as the Microsoft Macro Assembler (MASM)."

Ti quoto quello che hai scritto tu

Originariamente inviato da cdimauro

- Visual Studio (col quale è compilato Office) NON supporta l'assembly x64 e ARM: "Inline assembly is not supported on the ARM and x64 processors", ma Office è già disponibile da tempo per queste architetture.

Da "non supporta la sintassi inline" "non supporto assembly" mi sembra un bel salto logico.

Non ne ho bisogno, grazie. Il tuo esempio dimostra che devi ricorrere a un assembler esterno, come riporta la suddetta documentazione Microsoft. Cosa ovvia, e che peraltro puoi fare anche con linguaggi di programmazione diversi, ma è un'altra cosa rispetto a poter avere assembly inserito direttamente nel codice C/C++, che è di gran lunga più comodo, semplice, e non richiede salti mortali quando hai a che fare con applicazioni complesse, soprattutto se OOP.

A me pare che il mio esempio abbia smentito la tua affermazione. Il "tool esterno" è un componente della suite che viene installato assieme a tutti gli altri se selezioni il supporto C/C++ nel setup.
E se non sei un folle che scriveva assembly inline in ogni file, e hai dato una struttura decente al tuo progetto, rinunciare a questa piccola comodità non lo ritengo un gran lavoro.

Cercare di cambiare discorso è perfettamente inutile. Avevi detto questo:
"I problemi dei formati di Office sono stranoti, non capisco perché insisti a dire che sono aperti e documentati"
che è palesemente falso, come ho dimostrato.

A me pare invece che la pagina di Wikipedia che tu stesso hai linkato dice esattamente quello che io e molti altri abbiamo detto: quello standard è farlocco.


E adesso basta, chiudo qui la discussione.

[cdimauro]

Originariamente inviato da biffuz

Ma cosa c'entra C# adesso?

C'entra perché se scrivi questo:

"sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi"

ti ho fatto un esempio in merito.

Java e C# a mio parere sono talmente simili che la produttività è questione di gusti e abitudini, e gli IDE aiutano molto, ma meglio che non scendo nei dettagli prima che mi chiedi le prove.

Ovviamente te le chiederei: non siamo mica al bar dello sport.

Credo che tu abbia ragione, d'ora in poi penso che inizierò ogni frase con "dubito fortemente", "sono ragionevolmente sicuro", "a mio modesto parere" o locuzioni simili, così se qualcuno mi smentisce posso sempre uscirne con "la mia non era un'affermazione, stavo solo esponendo un'opinione".
Mi pare anche che molti politici con gran seguito facciano la stessa identica cosa, dopotutto...

No, sarebbe sufficiente utilizzare la lingua italiana in maniera appropriata. Tutto qui.

Ti quoto quello che hai scritto tu

Da "non supporta la sintassi inline" "non supporto assembly" mi sembra un bel salto logico.

Gli assembler esistono da una vita e tutt'oggi non se ne può fare a meno. Dovresti sapere che i compilatori C/C++ e di diversi altri linguaggi ad alto livello generano sorgenti assembly, che vengono poi compilati dall'assembler per generare i file oggetto, e infine al linker per ottenere l'eseguibile finale. Dunque è ovvio che ci sia un assemblatore in questi strumenti di sviluppo, perché altrimenti non potresti farci niente (a parte sviluppare interamente in assembly, che lascia il tempo che trova).

D'altra parte il contesto avrebbe dovuto essere chiaro. Ecco qui quello che avevi scritto:

"Il fatto che gli engine di Office sono scritti in assembly è riportato in molti articoli"

Se l' "engine" fosse scritto in assembly, vuol dire che il resto NON lo sarebbe, logica elementare alla mano. Dunque l'avranno scritto in un ALTRO linguaggio di programmazione, e siccome a parte Visual Basic Microsoft supporta da tantissimi anni C e C++ e mette a disposizione anche librerie/framework allo scopo, mi pare scontato che la scelta sia stata questa.

Ora, il punto è che se passi a C/C++, e specialmente se poi utilizzi classi et similia (che col tipo di applicazioni che sono quelle Office mi pare una naturalissima scelta. E questo senza nemmeno tirare in ballo i design pattern), continuare a usare l'assembly 8086 (perché è questo che è stato usato inizialmente con le prime applicazioni del pacchetto Office) non sarebbe stato possibile, visto che già all'inizio degli anni '90 aveva preso piede l'80386 come ISA di riferimento (8086 era già destinata all'oblio, pur con tutta la base software esistente), lanciata dai famosi DOS-extender e dall'arrivo di Windows 3.0.

Dunque quando Microsoft avrà deciso di riscrivere Office in C++ non poteva più utilizzare il codice originale 8086, e se avesse voluto continuare a mantenere l'engine o, in generale, una parte del codice in assembly, avrebbe dovuto riscriverlo da capo per 80386. E la maniera migliore (ossia comoda, veloce, produttiva, ossia più facile da integrare e testare) di farlo è usare l'assembly inline, per l'appunto, i cui vantaggi sono innegabili rispetto all'avere blocchi di codice isolati in file assembly esterni.

Quindi se questa è la strada scelta, e di cui ho ben pochi di dubbi da sviluppatore, si giustifica la frase che ho poi scritto in risposta alla tua:

"Dubito fortemente che abbiano mantenuto il core in assembly, se non eventualmente per piccole sezioni critiche per IA-32/x86, per le seguenti motivazioni:
- l'assembly 8086 (di moda dagli anni '80 fino a circa la metà degli anni '90) è diverso da quello di 80386, e quindi avrebbero dovuto riscrivere tutto;
- Visual Studio (col quale è compilato Office) NON supporta l'assembly x64 e ARM: "Inline assembly is not supported on the ARM and x64 processors", ma Office è già disponibile da tempo per queste architetture."

che parla per l'appunto di "inline assembly".

A me pare che il mio esempio abbia smentito la tua affermazione. Il "tool esterno" è un componente della suite che viene installato assieme a tutti gli altri se selezioni il supporto C/C++ nel setup.

Come già detto sopra, è a dire poco OVVIO che questi strumenti includano un assemblatore.

E se non sei un folle che scriveva assembly inline in ogni file, e hai dato una struttura decente al tuo progetto, rinunciare a questa piccola comodità non lo ritengo un gran lavoro.

Non è questione di rinunciare a qualcosa: da sviluppatore valuto i pro e contro di ogni strumento, ed eventualmente lo uso (in toto o in parte) a seconda del problema che ho da risolvere. Cosa scontata per un professionista, e non credo sia necessario chiedere se si sia d'accordo oppure no.

E da professionista la mia valutazione sull'opportunità di usare codice assembly te l'ho illustra sopra: quelle sono le scelte che avrei fatto, e ho pochi dubbi che gli sviluppatori di Microsoft abbiano fatto diversamente quando hanno riscritto Office in C++, EVENTUALMENTE mantenendo porzioni in assembly.

Per il resto, sì: fino a circa metà anni '90 scrivevo codice quasi interamente in assembly.
Quando ho dovuto lavorare col PC per la scuola (ITIS) all'epoca si usava il Turbo Pascal 3.0, e l'UNICO supporto all'inline era... quello in linguaggio macchina. Dunque i miei sorgenti erano pieni di inline in esadecimale che derivavano da parti assembly (8086) compilate e di cui avevo poi fatto il dump per inserirlo, appunto, come inline in mezzo al codice Pascal. Alcuni moduli li ho mantenuti in assembly, da linkare all'occorrenza. Ma la via prediletta era l'inline, anche se limitato al solo linguaggio macchina, perché rispetto a un assemblato esterno da linkare mi forniva una notevole flessibilità (ossia poter passare parametri in mezzo ai byte, nonché inserire espressioni che venivano calcolate dal compilatore).
Con l'arrivo dell'inline assembly, col TP 4.0 se non erro, ho progressivamente abbandonato i moduli assembly esterni, e scritto il mio codice assembly direttamente in mezzo a quello Pascal, grazie agli innegabili vantaggi.

A me pare invece che la pagina di Wikipedia che tu stesso hai linkato dice esattamente quello che io e molti altri abbiamo detto: quello standard è farlocco.

Dovresti controllare meglio: ci sono critiche contro e a favore.

Ma in ogni caso il formato è aperto e documentato, contrariamente a ciò che avevi falsamente affermato.

Altra cosa di non poco conto, è la storia di questo formato: è stata l'UE a chiedere Microsoft di standardizzare il formato XML dei file prodotti da Office, e non il contrario. Inoltre è un processo che non avvenuto in poco tempo, ma ha richiesto due anni di lavoro.

Così si smonta un altro falso mito che circola da tempo.

E adesso basta, chiudo qui la discussione.

Per me puoi fare quello che vuoi.

[Giulio92]

Premetto che non ho provato OnlyOffice, ma resto dell'idea che la miglior soluzione siano i servizi di Google (Google Documents, Google Sheets...): 100% online, zero spazio su disco, accessibile ovunque ci sia una connessione internet. Nel complesso puoi fare tutto, io lo uso per scopo sia privato sia lavorativo dal mio account Google, penso che questa sia la soluzione migliore in assoluto!