Sanity happens. Now, if the templates are badly done with complex direct formatting, and if you have to go back and forth with
the proprietary word processor several times, or if it is ‘Open’XML, then bad things happen.

Not strange at all, if the original document used styles sanely instead of going for complex direct formatting.

When things really break is when one has to collaborate with people who resist to LibreOffice on some badly formatted document, and then you have to convert to
and back again several times.

Sorry, I did not get your point. But yes, unfortunately I am often required to use it.

That was my point.

But I actually think it is not only the proprietary file formats being bad. It is also that the proprietary suite falls short
in organising documents with styles and templates, so people use very complex direct formatting.

Quite to the contrary, LibreOffice deals better with long documents than the proprietary alternative, and also it never
corrupts complex documents like the proprietary alternative.

The only fundamental way where LibreOffice falls short is when dealing with unnecessary complexity in the proprietary suite
files. Complexity which is fairly common, given the proprietary suite deficiencies in structuring documents.

Lack of knowledge is so sad. One has only to have a passing understanding of data models to read Reiser’s paper and realise he
does not understand the fundamental concepts of the field. Such a waste of time, money and talents.

Or, when will it run on GNU/Linux?

Yes, they do. The few of them, that is. SQL DBMSs do not, but they are not relational.

This makes little sense to me, because it describes not a key-value store — unless you consider the ‘value’to be all
non-primary key columns, which would stretch the definition of a key-value store —, but a relational database relation.

Not a Book, but an article. Granted, Codd published a book aftwards, but that was not original anymore.

Precisely.

Not sure about what do you mean with relationships here. Relationships are a concept of ERDs, not of the relational model.

They were never a price oriented company.

This is not true at all. Nearly all markets Microsoft entered they underpriced, usually a lot. Operating systems, server
software, office suites, you name it — MS products were always cheaper than the then incumbent. What MS always
did was to establish a proprietary lock-in by embracing, extending and extinguishing existing standards, so that they
could avoid lowering prices — software having fat margins, former incumbents would underprice MS once they lost in the
market, so avoiding a price war was of essence.

As far as I know this is the first time Microsoft enters a new market — actually, reenters a redefined market, as they failed to
develop the market for tablets with their MS Windows for Pen Computing OS version and are now playing in a renewed by Apple
and Google market — overpricing it. Netbook history, where Asus created the market with GNU/Linux and forced MS to lower the
price on MS Windows XP, seems to indicate where will MS Windows RT prices will go after a few months. Downhill.

I do see how F1 is a fuller featured DBMS than Spanner, but it seems less relational, if it does not require that tables have
keys.

Tables without keys are not relations, so one could argue that Spanner is more, not less, relational than F1 and other SQL
systems.

From the original paper linked at the summary post above:

OK, relational keys should not be ordered. But the fact that each table must have a key makes it a relation, at least in
principle, so Spanner at first looks like it is in fact more relational than SQL. Am I missing anything?

It seems at least one FAA certified product is a set including Flight Gear, so I would not use that to say X Plane is the only serious flight simulator to run on Apple Mac OS X & GNU/Linux.

What makes X Plane more serious than Flight Gear, let alone the only serious one?

Why? All the others were equally touted, the difference being the situation was never as dire as it is now for MS WinCE.