Showing posts with label ms office. Show all posts
Showing posts with label ms office. Show all posts

Tuesday, January 4, 2011

Microsoft Office and ODF: Best Practices

Sorry for yet another bookmark post, but knowing how often I hear about this kind of compatibility problem, I thought this article was rare enough to notice: Rob Weir details how to handle ODF (Google Docs, OpenOffice, LibreOffice...) in Microsoft Office, version by version, from Office 2000 to Office 2010.

Friday, June 26, 2009

Raw unrefined suggestion about firewall rules

Since now we see attacks from inside intranets, using zombie networks, I think it could be a good idea to turn on the firewalls on each machine in the network (including on Windows stations, which I know is sometimes a problem) and to set up a detailed set of rules for them.

My problem was: how to figure out which rules for such a complex problem, so many machines?
My suggestion: why not propose a standard for a single file giving the positive rules necessary for a software to operate?

One file per application, that would come shipped with the application, and would describe all the things that need be open, for the application to work. The file would not describe what set of rules to put on which firewall, but simply what needs to be open.

If we have a look at the TCP/IP layers
TCP/IP layersThis picture from Wikipedia under the GFDL license.
we see that simple firewalls operate on the Internet and Transport layers. Modern firewalls and proxies also operate on the Application layer.
I guess a simple XML dialect could be created to describe which things need be let in and out, on which layer. If this gets standardized or at least RFC'ed, there is a good chance to see opensource software adopt it, both on the application and on the firewall sides. On which case, since opensource is biggest marketshare on infrastructure, others should follow.
(All that raw and unrefined.)

Wednesday, May 6, 2009

Can new MS Office format replace correctly old MS Office format?

A few friends of mine are concerned that the new MS Office format OOXML (discutably standardized as ISO/IEC 29500) might not replace correctly the previous one. Should they change their organizations' practices to the new OOXML or stay put with the old .doc, .xls, .ppt and so forth?

One assumption was that Microsoft would write the file format to allow for a correct representation of all the previous content. This was in their interest because they then could say to their customers that the transition would be seamless.

However they were criticized for including say "direct representation of old formats" rather than "complete representation" of the same data. Or more simply, they made OOXML represent the mechanisms of the old .doc and .xls, rather than provide something to represent the same information in a unique, coherent new architecture. This means that the OOXML format inherits a lot of the complexity and some bugz and patchz of the previous formats. But it's not my point today.

My point is that when doing this, they forgot things (due to the high complexity of the previous formats I suppose), which made a subcomitee of the ISO say that it is "impossible to fully represent some of the corpus of existing documents in [OOXML] ISO/IEC 29500". So to the questions of my friends about switching to OOXML, my answer is: wait and see.

If there is one thing I am sure about, it's that we have a lot to see from MS competitors: IBM has its own branch of office suite linked to OpenOffice.org, Oracle has just bought Sun's OpenOffice.org and Google will not let go of online edition.

If there is one thing I am convinced about, it's that OOXML is not a mandatory shift so far.

Sunday, November 2, 2008

ODF vs OOXML: Being impartial, and having people work

I was recently confronted with the question of having my users open any kind of office files they would receive as attachments. It gave me an occasion to review the whole controversy on Office Open XML, the new Microsoft format. And I didn't get any further by reviewing it :-(
As matter of fact, rather than focusing on solutions like ODF, OOXML, or their implementations in MS Office or OpenOffice.org or others, I think the good way to take the question is to focus on the problems we have to address and define them better.

  • Why did we need to change? What were the problems in the previous formats of Microsoft Office?
  1. Vendor lock-in: because the format was not publicly documented, competitors could not implement it. They could not write competing software, resulting in a slow down of quality and support from Microsoft.
  2. Bad support of previous versions: some files created with older versions of Microsoft Office cannot be opened with newer versions. This is especially true of Powerpoint slideshows. Even when a file can be opened, it is very common that the layout of elements doesn't look the same on different MS Office versions or different Windows versions.
  3. Viruses: because the format was binary, and not publicly documented, it was easy to hide viruses in it, and hard to detect them. Lots of botnets have been created because of the funny powerpoints that are forwarded from employee to employee.
  4. Heavy and limited format: the format inherited incoherences from its previous implementations, making it heavy to implement, and resulting in heavy files.

  • What makes the best format?
  1. Vendor lock-in: ODF suffers no limitations, the standard evolves, and can be implemented freely. Microsoft have said they will let competitors implement OOXML freely and they will publish modifications to the standard. Yet we have historical reasons to doubt this will be their policy.
  2. Viruses: ODF is a complete XML format, which can easily be scanned against viruses. OOXML allows for binary parts in the documents, thus enabling viruses.
  3. Weight of the format: Both are mostly text based and use a zip compression, obtaining comparable results for the size of files. ODF makes re-use of other standards such as HTML or SVG, allowing for cheaper implementation, whereas OOXML starts all from the ground up.
  4. Implementations: Currently, OOXML is completely supported only in Microsoft Office 2007. ODF is completely supported in OpenOffice.org, StarOffice, Symphony, KOffice, Google Docs and others.
From a technical point of view, ODF is by far superior to OOXML.

  • What do we face now?
  1. Both ODF and OOXML have been promoted as ISO standards (26300:2006 for ODF and 29500:2008 for OOXML.)
  2. Some companies have updated to Microsoft Office 2007, which saves by default as OOXML. Some companies have turned to OpenOffice.org which works natively with ODF.
  3. So the result is that company users receive daily legacy binary .doc, .xls, .ppt and ODF documents and OOXML documents.
  4. The most common Office suite is still Microsoft Office 2003, which works neither with ODF nor with OOXML.
  5. Many companies don't have enough Microsoft licenses for all their workstations and implement OpenOffice.org where they don't have license.

  • To the point: what do we need now?
  1. Have both formats work with MS Office 2003, or pay and have them work with MS Office 2007. This seems to be possible with a "conversion environment" from Microsoft (to open OOXML) and a plugin from Sun (to open ODF).
  2. Have both formats work with OpenOffice.org, where Microsoft licenses are not available. ODF is natively supported, and the implementation has started for OOXML. OOo should have working OOXML in short time.

As a conclusion, after spending quite a few hours on the question, I can tell that ODF is a technically far better solution, and that it should be possible to maintain people working through this cacophony with additional plugins for MS Office.
Of course, as usual, implementation will be the most important part. I will post about the implementation of plugins when I have results.