CyberTech Rambler

January 22, 2008

Its inevitable

Filed under: Uncategorized — ctrambler @ 5:12 pm

“Virtualization does not make sense to non-business customers”, said Microsoft when it decided Windows Home (and Home Premium edition) cannot be run as virtual machine. From day one, it is nonsense, David Berlind’s post on ZDNet,  clearly shows the benefit of virtualization to joe users.

I always maintained that this restriction has nothing to do with benefit to users, but a business decision to maximize revenue. Why sell a cheaper one if you can get the market to bear a more expensive option? I know it is only a matter of time Microsoft will capitulate. And capitulate it did. It finally announce that it is going to be possible to use Windows Home edition on virtual machine.

Microsoft’s finally hit by its own bad practice in standard conformance

Filed under: Uncategorized — ctrambler @ 5:04 pm

Who would had thought it, Microsoft find itself needing a ‘quirk’ mode in IE8.

‘Quirk’ mode had been common in other browsers such as Opera. They need it because IE is doing an extremely bad job in standard conformance.

It’s great that Microsoft finally have to taste its own medicine. The strange thing is, to Microsoft, web standard conformance is the ‘quirk’, not its bad implementation of standard. This irks some commentators. I take a more practical route: in IE8, quirk is standard conformance, but in IE9 I want to see ‘IE7′ as the quirk.

What will Mirosoft do next? Browser spoofing?

January 21, 2008

Partial support for OOXML is not much to brag about

Filed under: Uncategorized — ctrambler @ 11:33 pm

Right now, two posts from Microsoft camp (Brian Jones and Gray Knowlton) which brag about Google and (surprise, surprise) IBM’s support for OOXML is making its round around the internet grapevine.

Did they get it right? Partly. Jones conveniently omit the fact that searching into OOXML files is simply consuming OOXML. Google had so far, not yet allow its document production part, i.e., GoogleDoc, to produce OOXML file. Knowlton also conveniently did not give reader the big picture about the article he quoted: OOXML is not supported out-of-the-box, but rather you can perform some maneuvre (and install a file) to get a IBM product to read OOXML.

For me, support means full support, i.e., both consuming and producing OOXML file.  I need roundtrip to claim support. Ditto for ODF. Any application that fails to do production when where it can is a ‘honey trap’. It is designed to ensnare users to the application. So Apple’s iWork is a honey trap. Novell’s bastardized version of OpenOffice.org supports OOXML is not, because it does both. As for those application that does not support production, I simply do not think it is right to claim support for the document format. Adobe Acrobat Reader reads PDF file fine, it can even fill in a PDF form. However, it cannot save your files, even those filled form, in PDF. As such, it does not fully support PDF.

For the pro-OOXML camp, it is sad to see that they lower themselves to defining OOXML support as anything that reads OOXML just to make the headlines. Years of MSOffice dominance means sadly, there are few office applications to support either format. A better headline will be to demostrate other applications that writes its data to OOXML then read it back from OOXML. This is one of the point I think OOXML has a much better chance to pull off compared to ODF, i.e., integration into office automation. Its custom XML approach is not good for interoperability in the long run compared to the XForm approach. For ease of use viewpoint, however, its easier to extract data if you can define the XML syntax itself, which is what custom XML offers.

IBM and Google have software components supporting OOXML that they did not tell us about? Is it a surprise? Not to me. They expects to leak them out without pro-OOXML finding out? That will be a miracle. Grudgingly, MSOffice supports ODF, abeit indirectly. To say that IBM (to a lesser extent, Google) can totally avoid OOXML is equally impossible. The only realistic question, is there obstacle to using OOXML. Does OpenOffice.org supports OOXML? Most will say no, although in reality, in reality, it does, in the form of Novell’s OpenOffice.org and the availability of the same plugin for the vanilla OpenOffice.org. Therefore, the fact that IBM put obstacle, i.e., requires the administrator to do extra work, is an important factor in considering whether IBM has OOXML support.

I can argue that at least IBM throws its official support by taking responsibility for OOXML if you want it, but Microsoft decided to use a roundabout way to avoid responsibility.

I would like to repeat my disdain for partial support for either file formats. Don’t set ‘honey trap’. Either don’t support it at all, or support it fully.

An (unexpected) sigh of relief when SUN bought MySQL

Filed under: Uncategorized — ctrambler @ 10:40 am

When SUN bought MySQL, I was surprised. Not that the acquisition happens, but that I was relax about the buyer is SUN.

MySQL is ripe for acquisition. A company on the up and the shareholders (rightly) wants to cash in. The question is who will buy it. The problem with MySQL is that it has too much control of the open source database system it is both giving away as open source and selling a commercial version. In fact, a lot of MySQL value for open source will disappear if it is bought by someone who is not well versed with open source. It need not be the one from Redmond, something like Oracle will do the trick just as nicely.

Acquisition by SUN a few years ago would had sent alarm bells ringing for me. However, compared to his predecessor, Jonathan Schwartz seems to someone one can trust in handling open source. That is what surprised me. I had been viewing SUN with a bit of suspicion when it comes to open source since the McNealy days. However, the fact that I was relax with the MySQL acquisition shows that my view of SUN had changed unconsciously over the year(or is it years?). Something unexpected.

January 19, 2008

When must revision be rejected?

Filed under: Uncategorized — ctrambler @ 6:38 pm

Brian Jones had just blogged that more compatibility settings in OOXML is going to be defined more properly. Along with the announcement about other changes, OOXML is finally making a start on the long (and bumpy and whining) road to become an acceptable international standard, rather than a proprietary and vaguely defined rubbish it was.

Now, bear with me. I am taking you on a detour here. My intention will of course be clearer later. Imagine you have a seat in your company’s committee defining Standard Operating Procedure (SOP) for others to follow when they perform a certain complicated task. Previously, the authors of the SOP submitted their near-to-final draft for comments in a meeting. In that meeting, the consensus was there are some recommendations that the authors should consider when writing the final draft. Today, you received the final draft. After flipping through the pages, you find that there are a lot of new material and significant rearrangement of presentation order. Now, let’s make the assumption that they are all for the good of the SOP. However, looking at your calendar you realize that there is insufficient time to properly review the changes before the next meeting? What should you do?

My recommendation? Ask for an extension immediately. Failing that, at the next meeting, you will have to consider seriously the option of rejecting the proposal. After all, a bad SOP is worse than no SOP at all, especially if the changes have Health and Safety implication. I hope you agree with me on this.

Back to topic. So far, nobody, with exception of National Body and ECMA members I suppose, seen the revised OOXML standard. However, from Brian Jone’s discussion, it is clear that there were significant changes. Some changes, such as adopting ISO Dates, requires careful scrutiny. The description of compatibility settings, as Jones described in the first linked blog posting will all need to be independently checked for accuracy and correctness.

By introducing these at such a late stage, there is a possibility that the required due-process is not possible for the changes proposed. National Bodies’ working committee will certainly do not have the time considering the fact that the next Ballot Resolution Meeting is about a month away. The alternative, not as good as the signal-to-noise ratio is high, is to open up the specification for everyone to see and hope that the virtue of “many eyes” will achieve the desire effect. So far, we have none.

That is alarming, if the changes is as substantial I think it is. Just on top of my mind, insertion of about 20% more material, in the form of description of the “compatibility settings”, some changes that really need close scrutiny, such as ISO date insertion and the reorganization of the already substandard writing. In effect, I think it qualifies as a new revision, not an update to existing draft.

ISO fast track process is intended to make the road to ISO standardization faster for ready, well-studied and well formulated standard defined elsewhere. It make sense that if another standard body had scrutinized the proposed standard already, ISO need not go through the process again.

In the case of OOXML, it is blatantly obvious that OOXML was no where ready when it was proposed to ISO. At the very least, the writing is bad and not something you expect to see at international standard body level.

These changes should not had happen at such a late stage. They should had been discussed in ECMA committee stage. I am not asking the ECMA committee to adopt all changes, but rather, if they reject these rather obvious omission, they have an explaination for it, made public together with the proposal the standard to ISO. The only conclusion that I can draw is that the ECMA committee, despite consisting of big names such as British Library and Apple, was sleepwalking.

We should, however, recognized that OOXML proposers had made significant move from their original position. We must give credits where credits are due. My recommendation, assuming my speculation turn out to be true, is to reject OOXML this time, but with the recommendation that ECMA address those issue carefully (or better, the creation of an ISO working committee to take over the work from ECMA) and resubmit it at a later date.

January 15, 2008

Incorrect conclusion, besides alienating the very people we need to convert

Filed under: Uncategorized — ctrambler @ 12:46 am

Some of the analysis around September ballot on OOXML, although done with good intentions, i.e., against a a bad standard being adopted by ISO, are quite simply misguided. The first problematic one I see was from EFFI about corrupted countries are more likely to support OOXML, which uses rather crude analysis. This made it not as bad as the latest one from Digistan which try to measure the relationship between GDP and the voting pattern. They erred spectacularly as they uses statistics that might not support their conclusion.

The problem? Alienating the very people one have to win over. Don’t get me wrong. I do not condone corruption. It is bad. FULL STOP. We need to stop it. FULL STOP. NO IF…, NO BUT… There is only one sure way to kill corruption: Make sure corruption does not pay. Hit both parties: the people who offers and the people who accept the bride. To penalize the people who offers bribe, fight fair and make sure the person who offers the bribe does not get what they want. On the way there, keep one’s eyes and ears open and expose particular corrupted practices from manipulation of rules (and room size) to outright “bribing” and whereever possible, punish those who accept the bribe. The battle here is to unearth and publicize incidents of wrongdoing by showing evidence of it happening. General statement like “corrupted countries are more likely to support OOXML” group is unproductive. It makes it sounds like you are shouting slogan, or is simply a sore loser. Worst of all, it catches countries that geniuinely believe OOXML is OK in the net as well. When this happens, all we do is to supply ammo to others that will jump on the opportunity to call us zealots. Worse, it alienate the “uncorrupted” countries whose opinions we need to fight to change.

Although seriously misguided, at least the EFFI is looking at something universally regarded as bad: corruption. The Digistan article target? Wealth. I know that its intention is to imply a big OOXML supporter is trying to buy its way, but the message can equally be perceived as if you are poor, you WILL be bought. Taking into account that the global wealth picture is shaped by history, the sensitivity of a lot of people who thinks (rightly or wrongly) that they are put into that situation by the force of history against them. Since Digistan is a Belgian website, there is an extra perception that it is yetanother exercise by rich country to preach to poor countries about corruption and the proof that rich countries are so snobbish that they believe they are immune from being bought (Not true, rich countries just cost more to bribe). Does this helps our cause?

Worse of all, the statistics does not appear to support their conclusion that the alternative hypothesis, i.e., “The average of GDP per capita of the countries who voted for the OOXML proposal is significantly lower than the GDP per capita of those who voted against it. They used the Wilcoxon rank sum test, which is equivalent to most people’s favorite statistics test, the Student T-test. In fact, being a non-parametric test, Wilcoxon rank sum test is probably better than the standard Student T-test because it does not make a fundamental assumption with t-test, i.e., that the underlying distribution is a gaussian distribution. However, every statisticians, every statistics teachers and every statistics book will tell you that the test will only allows you to reject or accept the null hypothesis and says NOTHING whatsoever about the alternative hypothesis.

Hence, if you take their statistics test, i.e., that “there is no significant difference between the average GDP per capita of countries who voted for OOXML and countries who voted against it”, their test appears to support the fact that this hypothesis is not true, leading to the conclusion that “there is significant difference between the average GDP per capita of countries who voted for OOXML and countries who voted against it”. It says nothing about whether the average GDP per capita of countries who voted for OOXML is higher or lower than those who voted against it. If they wanted to answer the question, the test will have to be reformulated to be “the average GDP per capita of countries who whoted for OOXML is significantly lower than those who voted against it”, which they did not. Furthermore, although they publish their raw data, they did not publish how they measured their test statistics. Making it difficult to check whether their test statistics support support their conclusion. My belief (without proof) is that they simply use the GDP values as the test statistics. If so, it is unlikely that their statistics test is different from what my proposed reformulation of the null hypothesis will requires.

(Aside):

Statistics is maths, and maths will always give you an answer. The role of anyone performing the statistical analysis is to make sure you collect the correct data, perform the correct mathematical manipulation of your data and to perform the correct statistical test.

That is not easy, and that is why all respectable journals will require you to expose your test method and walk the reader through what you did. Even with good journals, sometimes their referees can sometimes miss it. Recently, I think we caught thre instance of this happening. The question to answer is “Is group A behave differently from group B under drug X?” A research group published at least 4 papers on this. The first three appears to do two within-group analysis and use them to draw a conclusion. In other words, they ask “Is group A behave differently when drug X is used (with respect to placebo)” and the same for group B. What they found is that group A is behaving differently when drug X is applied, but group B does not. They link the results together and say that therefore group A is behaving differently from group B. I concur with my colleague that this might not be the case. Statistically speaking they haven’t compared group A with group B. They should had compared groupA’s drug A performance (w.r.t placebo) with that of groupB. The difference is subtle and difficult to grasp and explain. And I believe the referess miss this or probably overlook it. The statistical test I believe they should had done has been the standard test for at least 5 years before the first paper was publish. Therefore, they probably assumed that they did the expected test, or more likely, decided that their conclusion is correct despite the imperfection in their analysis method. I think the referrees saw the later as in their fourth paper, a new co-author appears to have spotted and corrected this problem. Good for them (and the research field.) What really struck me is that, if you ask me when I completed my PhD and before I take on this current job of mine, I will tell you this is OK.

January 9, 2008

Endorsement of Open Source Security (updated)

Filed under: Uncategorized — ctrambler @ 6:53 pm

A while ago, Homeland Security spent some money to get a source code analysis company to perform an audit of popular open source code. The results and follow ups is reported in this Information Week article (11 Jan – vital updates here) Some commentators in the comment section says that this is simply FUD ammo for closed source company to fire at open source community. I disagree. Sure, it is possible to use this as a FUD bullet, but the article is not FUD, but a careful reading of the article shows that it is a ringing endorsement of Open Source.

At the very least, it shows that with exception of Firebird, (Corrected on 11 Jan, after reading the correction here) all open source project investigated takes very active steps in investigating and correcting the flaw identified by the company. The speed of correction is also very impressive.

Every software has vulnerability. Moreover, the very presence of bugs identified by the “Process”/analysis approach used by the contractor proves that the “Process” approach has merits. Anyone who want to spread FUD will concentrate on the absolute bug count. However, the more impartial (but still faulty) approach is the error rate, or bugs per line. If we take the first sentence of the article as the absolute truth, it appears that the current open source process is as good as whatever processes close source company deploy. This cast further doubt into the FUD article championing the “Process” approach by Microsoft

Moreover, the results from various open source project shows that the theory that “More eyeballs make bugs shallow” holds some water, as Linux has lower error rate than other, less popular project.

Note that as we do not have the results for close source software to compare with, we cannot, based on these results, says that they are better/worse in handling security and other vulnerability issue. Unless they are willing to subject their source code through the same test methodology by an independent company, any close source company trying to capitalize on this must be viewed with suspicion and can be accused of spreading FUD.

January 2, 2008

Larry Dignan’s review of OLPC

Filed under: Uncategorized — ctrambler @ 2:00 pm

Larry Dignan’s review of OLPC is a must read.

Some fun bits:

  • His 5 year old daughter fares better than him in flipping it open
  • For 5 year old : Paint is good, camera better, just not email
  • Ruggedness proven. I feel his pain when his kid toss it around, spill liquid and chocolate on it.

Above all, it is clear that the design is for kids and not adults. In fact, at times, being an adult is an disadvantage ;-)

It is also not unfallable. It crashes sometimes. It is so far too early to say whether it is teething problem or something more serious that will last a few revisions.

The points Dignan made about Windows usability issue on OLPC with reference to young kids (<10 years old) is a good one. He  thinks Microsoft cannot do it. While I agree Windows XP as it stands will not fit the bill, there is  hope for Windows aficionados: (1)Windows XP, as it is, will appeal to older kids (>10 years old), (2)Microsoft has the resources to rework Windows for kids (<10 years old), if they choose to and (3)They will rework Windows for kids as they probably feels (rightly) that they cannot afford to lose out.

Blocking older file formats in MS Office SP3: Slightly misguided

Filed under: Uncategorized — ctrambler @ 12:24 pm

The news on the grapevine is that Microsoft Office Service Pack 3 is blocking older file format on security ground. Given that they are mostly pre 1997 file format, the impact is going to be low. Unfortunately, as the linked article show, it is difficult to reenable reading those older format. This, I think, is a mistake.

I am not against the idea of blocking older file format, simply that the workaround is too complicated. Nowadays the number of files still in the old format in circulation is low. This undoubtedly contributed to the decision to block. On the other side of the coin, the security risk is more remote as time passed, so, why not make a reenabling it a much simpler workaround for the user? Requiring users to check a box in the “Preference” menu than nagging them to answer “Yes” to “Do you really, I mean, REALLY want to open this less secure document?” every time they access these file format seems reasonable to me. OK, may be I throw in a requirement for Administrator to set a registry key to say “Allow user to enable older file format”.  After all, Microsoft is providing a “Registry Template” for sys admin to enable older formats. To hunt around Microsoft’s knowledge base articles for workarounds is not an easy task for joe users. The complicated and riddle with danger (by Microsoft admission) way turn this into a bigger issue than it should.

The Rubric Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.