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

Ma questo è un forum qualunque.

Chiedo scusa ma non ho né tempo né voglia di scrivere saggi dettagliati per ogni post su ogni forum.

Se lo fai, il 99% delle persone non lo legge e il restante 1% si mette a dibattere sulle virgole (senza fonte). O comincia a chiedere la dimostrazione che 1 più 1 fa 2.

Se qualcuno ci tiene, può cercarsi tutte le fonti che vuole su Google, Wikipedia, Stack overflow (lo usano tutti - senza fonte - e non dite che non è vero), documentazione ufficiale, libri scolastici e via dicendo.

A me sembra la solita lotta tra i programmi open e quelli microsoft, lotta senza ne vincitori ne vinti, office continuerà a essere il programma di riferimento per l'ambito lavorativo, libreoffice continuerà a non essere un buon sostituto perché non compatibile al 100% con i formati microsoft, quindi di fatto se devi collaborare con delle persone che usano office lascia stare, comunque non è un forum tecnico, non siamo tutti programmatori, io sono un analista numerico figurati, le interfacce grafiche per noi andrebbero abolite, consumano risorse inutilmente...e comunque per l'uso che ne faccio io fanno pena entrambi, latex tutta la vita .

Mi correggo da solo, Office nell'ultimo decennio è stato sviluppato in C++. E stavolta mi sento buono e vi metto pure una fonte.
https://channel9.msdn.com/Shows/Goi...n-C-Renaissance
Il porting su mobile e persino sul web sono basati su questo (webassembly). Le fonti ve le lascio da trovare come compito per casa.

Quando buona parte di quello che scrivi sono formule o simboli matematici è l'unica opzione, l'equation editor di word è una follia, va bene per piccole cose, ma niente di più, libreoffice/openoffice molto meglio visto che ci si può affidare al codice, ma i risultati finali dal punto di vista "visivo" non sono gran che, insomma va bene per uso personale, ma niente che si possa presentare a qualcuno.

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:
[I]"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."[/I]

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.

Ma proprio no. Vatti a vedere cos'hanno fatto con OpenDocument, quando è stato standardizzato: non avevano nemmeno specificato il formato delle formule! Sì, proprio delle formule! Incredibile, eh? Il bello che veniva spacciato come il formato per eliminare i problemi di interoperabilità... lasciando assoluta libertà a chiunque di definire le formule come volevano.

Questa come al chiameresti tu? Porcata?

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.

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.

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:

[I]"Inline assembly is [B][SIZE="7"]not [/SIZE]supported on the [U]ARM and x64[/U] processors[/B]."[/I]

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

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.

Io sul tecnico ci sono già entrato e ho illustrato le problematiche note dei linguaggi citati.

Non direi proprio.

Sei buono a smentire te stesso? Bravo.

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.

chi ha voglia di tornare in topic?


vabbè, oggi che ho poco da fare proverò questo OnlyOffice, prendo il docx originale che mi ha creato tanti problemi e lo apro sui diversi programmi poi scelgo quale tenere

p.s. giusto per mettere un piede off topic, 365 è solo in abbonamento?

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.

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é.



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.



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.



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

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.

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

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.

Continui ad avere problemi di lettura. Ecco cosa riporta quella paginetta:
[INDENT][I]"[SIZE="7"][B][U]Inline[/U][/B][/SIZE] Assembler
[...]
You can use the inline assembler to embed [B]assembly-language instructions [U]directly[/U] in your C and C++[/B] source programs without extra assembly and link steps. The inline assembler is built into the compiler, so you [B]don't need a [U]separate assembler[/U] such as the Microsoft Macro Assembler (MASM)[/B]."[/I][/INDENT]

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.

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

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.



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...



Ti quoto quello che hai scritto tu



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



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.



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.