2008 Jan 17 - Thu
Open Document Format Alliance Refutes the Burton Group Report on ODF
I have to say, starting out, that I do use Open Source productions as much as I
use Microsoft products. Each has its merits.
On the other hand, Microsoft would prefer that I use their products exclusively. I don't
think so. Interoperability is not really an allowed word in their books. The words extend,
embrace, and extinguish do feature prominently.
Much has been said, written, and done with regards to their OOXML format, which they are
trying to ratify. As it turns out, the standard they are presenting does not fully
represent their formats. Perhaps with some recent releases, that may be resolved. But with
a standard, an incomplete one at that, already at 6000 pages, additional information
releases just adds more bulk.
On the other hand, why can't they just allow an ODF transalator into their main 'Save As
...' menu? Why make things complicated. Oh. Sorry. I know the answer to that one... to
keep the competition at bay.
If Microsoft's shareholders were polled, do you think they would want Microsoft to
continue in the vein they are currently, or to inject a certain amount of ethical, healthy
market competition into the proceedings? After all, they started to thrive once IBM
openly published the specs for the PC. Instead, Microsoft publishes only what they need to,
and only at the lash of the whip of the European Union.
The basis for today's rant is an article over at Groklaw entitled
Open
Document Format Alliance Refutes the Burton Group Report on ODFM. The Burton Group had
developed a report which has quite a few false facts. ODFA has refuted them. I just wanted
to add my bit in publicising the counter to the fear, uncertainty, and doubt.
And I hope reason prevails when the OOXML vote comes up in February.
[/OpenSource]
permanent link
Crypto++
The C++ library,
Crypto++, has an amazing array of
crypto routines, including stream cyphers, block ciphers, message authentication codes, hash
functions, public-key cryptography, elliptic curve cryptopgraphy, as well as hold-over
insecure and obsolescent algorithms.
I'm using the library for a relatively simple task of using SHA-1 hashing on user
passwords for a variety of software applications I'm in the midst of writing: blog
routines, IP addressing documentation, and network management.
In the readme file in the archive is a couple of paragraphs I found as succinct
descriptions of what to do in contstructors with C++ references and pointers:
1. If a constructor for A takes a pointer to an object B (except primitive
types such as int and char), then A owns B and will delete B at A's
destruction. If a constructor for A takes a reference to an object B,
then the caller retains ownership of B and should not destroy it until
A no longer needs it.
2. Crypto++ is thread safe at the class level. This means you can use
Crypto++ safely in a multithreaded application, but you must provide
synchronization when multiple threads access a common Crypto++ object.
The first paragraph talks about constructors, the relationship of who does garbage
collection, and a clue as to when pointers whould be used and when references should be
used. The second paragraph, is, really, a kind of throw away, in terms of multithreading
practices, but at least it is honest with what it can do.
[/OpenSource/Programming]
permanent link
|
