A couple of weeks ago, I wrote about an impending meeting with Microsoft to discuss some of its actions during the standardisation process of OOXML at the ISO. I asked Linux Journal readers for some help in preparing for this, and you responded with a generosity entirely in keeping with the spirit of free software. The many helpful comments to that post give some indication of the scale of the response, but that overlooks the extraordinary emails I received from others, packed with useful information, which clearly represented many hours' work. To everyone, I'd like to express my thanks. The bad news is that the meeting is not going to take place after all.
That's not because either I or Microsoft chickened out, but a consequence of the fact that the CIO of Newham, Richard Steel, for whose benefit the meeting was being held, has rather suddenly and unexpectedly announced that he is retiring. In the wake of this news, I contacted Microsoft, and we agreed that there was little point holding the meeting as originally planned.
However, I was very conscious of the huge amount of effort that people had put into this matter, and so I wondered how that might be salvaged. Since the issue of how Microsoft behaved during the ISO process is still a very live one, it seemed to me a worthwhile exercise trying to pull together a summary of certain aspects of what happened last year. Since the whole point of doing this was to hear Microsoft's response, I asked the company whether they would be interested in writing a reply to my post, and they have agreed to do so. Quite what this will produce, I don't know, but I think it's worth trying. At the very least, there will be some more documentation of what happened, and maybe some new points from Microsoft too.
To clarify: what I aim to concentrate on is not the technical side – what was and still is wrong with OOXML as an ISO standard – so much as the procedural issues at the national level. Sifting through the wonderful resources provided by Linux Journal readers, I aim to pull out what seem to me the clearest cases of Microsoft bending the system to produce the result that it wanted.
I will omit the many vague accusations that were flying around at the time, simply because it wouldn't be fruitful to include them. Microsoft could rightly say that they are merely unsubstantiated rumours. Even though this will mean leaving out some of the more egregious flouting of rules, I think it will make the case stronger by virtue of concentrating on those incidents that are most substantiated and least easy to dismiss.
I'm currently putting that document together; I will then post it here and send the link to Microsoft for comments, which can be in whatever form they wish. I then aim to publish the comments, unedited, alongside my original post in some way, depending on what format Microsoft chooses. It will be interesting to see what, if anything, all this will produce.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- RSS Feeds
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Weechat, Irssi's Little Brother
- Senior Perl Developer
- Technical Support Rep
- UX Designer
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?