Stuff Michael Meeks is doing

Sun management has shown that ... they are willing to resort to rather hostile tactics to preserve absolute control. This is most certainly not in the spirit of open source and open development that we tried to foster or that Sun claims to embody.

• Over the last weeks it's been a privilege to be a small part of the team putting this together and scoping the work here, and I'm pleased with the outcome.
• What are we doing ? - we're going to bring the managed UIAutomation API to Linux over the next months & years. Of course, obvious questions as to how this interacts with the excellent existing Free-software a11y work get raised, so I drew a photograph of everyone working nicely together (new code highlighted):
  
  
  Please notice: that if you have some congenital allergy to Mono, this shouldn't bring on anaphylactic shock - it's a complementary approach. In addition any work we ship will be covered by a Community Promise shielding everyone from patent problems, in a similar spirit to IBM's recent Interoperability Specifications Pledge.
• Why are you doing that !?: I think it's a good thing (of course):
  • Clearly making apps accessible that were previously inaccessible is vital, and no-one I've talked to in the space seems interested in playing politics with that. Indeed with this piece the Free S/W a11y stack looks like it will soon integrate with all the significant toolkits, technologies & applications around.
  • This work will make both Winforms, and in future Moonlight accessible on Linux - adding to and improving the implementations of these toolkits. By extension that should make various vertical business apps accessible on both Win32 & Linux.
  • This is a fun space - as we started specing this out, I remembered fondly the good times of my a11y involvement: the excitement of getting anything working at all, and the serious late nights drinking with Bill Haneman, Peter Korn, Will Walker, the Baum guys etc. at GUADEC(s), the friendly debates over architecture, all that good stuff; somehow a different style from OO.o. Then of course, meeting other interesting people: Rich, Janina etc.
  • More eyes - embarassingly we've had some nasty snafus in eg. OpenSUSE 10.3, that we want to put behind us, being able to hire lots of new hackers to work in this space should make a real impact across the board. With them we should be able to improve everything from apps, to infrastructure, to ATs, and into packaging / distribution.
• What about the other hackers here ? - I think it's important, of course, to give tribute to Sun, without whose tireless work to make Solaris accessible there would be no Free-software accessibility stack. I'm looking forward to seeing us work more closely with Peter, Will & co. here. Unfortunately in the past our interest has been rather bursty - after a large chunk of work at the begginning, we settled into maintenance mode, helping out with some intractible problems here & there, and of course kick-started the native OO.o atk accessibility bridge. Then of course, there is IBM: with Rich, George Kraft, and their team, who have done some amazing work here: making Firefox accessible, funding infrastructure improvements, working on Accerciser, and of course IAccessible2 on Win32, driving interest & investment towards a11y. I'm looking forward to us working closely with everyone here.
• Not another huge spec !? - Anyone who takes the time to download and read the 4 separate specifications (of which we will implement only one: the managed part) can make some serious hay with the new SI unit of spec. complexity: page-count. On the other hand, this spec. is clearly just a 1st cut. This is the very start of turning it into something beautiful and, to my mind, that means removing the thousands of lines of C# and VBA examples that make up the majority of the headline figure. When instead you read the 1200 lines of equivalent IDL / and header-file interface description I for one learn much of what I need.
• What's next ? - I'm looking forward to help getting this project spun up, people hired, and working with some great guys: Rob Sinclaire & Norm Hodne from Microsoft to improve the UIA specification, work towards harmonisation with the existing stack, and so on. More about how the mechanics of that in the coming weeks. Oh, and of course - we're now looking for talented hackers in this space to hire. Mail me if you're interested please, regardless of location. Oh, and of course, I'm trying to persuade Marco Skambraks (our existing, long term, star a11y hacker) to start blogging to open up our work on OpenSUSE here yet further. Onwards interoperability & accessibility!

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

• Firstly, Charles is extremely generous with his advice on how people should license their code: yet it is not clear to me that he has ever written or contributed any himself, has he ? Secondly though he is well up for other people assigning their code to Sun, his explanation of why this is great falls horribly foul of the speculation that riddles his work: how does he know whom Sun has licensed other people's code to, and under what terms ?
• We also have an LGPLv3 conspiriacy (emphasis mine):

  So far Sun should be credited with having been extremely reasonable in regard of the license. In the future for instance, OpenOffice.org can switch to the (L)GPL version 3 quite easily. That could not happen without Sun's joint ownership, but for that matter, Michael Meeks' reaction was less than warm.

  This is easy to rebut; here's what Novell says about the GPLv3. I'm happy for OO.o to move to the LGPLv3 as/when/if Sun decides to do that (but ultimately it's only Sun's decision). As I said in my first post, I'm personally a fan of the LGPL for OO.o, my concern is that there should not be one company that doesn't have to accept the terms of the license. Also, a lovely excluded middle: of course, it's possible to re-license without Sun owning everything - there are at several solutions: eg. ownership by a foundation, or using the "LGPLv2.1 or later" language of the LGPL.
• Wrt. why we changed view on the JCA, I addressed that yesterday: and yes, I was wrong to encourage people to sign all their rights over to Sun, sorry; mea culpa - obviously I learn only slowly & by experience.
• Now, we come onto the real barn storming speculation (soon to become recieved wisdom) - real vintage groklaw journalism:

  Novell ... is also developing an OpenXML export filter that won't be available in OpenOffice.org that is, if you choose to use OpenOffice.org and not "Open Office, Novell Edition". And since these export filters are supposedly developed in collaboration with Microsoft, this technology would logically include Microsoft's sacred intellectual property that Sun and many others don't want to see covered by the JCA.

  Simply stunning, he knows of an effort going on in secret inside my team that I'm unaware of myself ! - more details much appreciated. Categorically, as of now, this is false; we're not actively working on native export filters to match the import filter. Furthermore my concerns wrt. Sun's ownership should be transparently free-standing, and are emphatically unrelated to Microsoft, in any way, whatsoever. It is also interesting to remember that Sun also has several well known agreements with Microsoft, around OO.o (or StarOffice). As for knowingly injecting other people's IP into OO.o that is a pretty repulsive accusation, and one rebutted before.
• Wrt. my apparently odd questions - I'm was interested in exploring options to hinder the use of GPL code in proprietary products, is that bad ? Interestingly my interlocutor there Allen Pulsifer has made his views on Sun's recent moves rather plain.
• Summary - vintage groklaw: conspiriacy theory dressed up as fact; with a strong pro-Sun bias. My problem with the JCA is around balance, equity, and proprietary licensing, not choice of license [ something over which as has been pointed out we have ~no real say ].

• First the light-hearted piece, I confess I missed out on mba's amusing pantyhoses piece, due (I think) to not being CC'd as asked in the quoted text (no doubt an honest mistake). The humerous example of the construction of a religious convictionally selective license is amusing: what is less funny is that only Sun chooses how OO.o is (privately) licensed, under what terms, and to whom.
• The historical review is most helpful, although at some level I think it ends up basically just re-stating the problem: that Sun demands total ownership of everything, and will continue to do so; but lets consider it:
• We stated in the ESC that we (Novell) are no longer willing to assign ownership rights to Sun for new, separable modules. Why ? If you're a particular fan of Sun, this can be seen as some malign and divisive strategy - after all, why shouldn't people want to assign their rights to Sun en-masse ? Of course we talk to Sun and others about improving OO.o continually, but the simplest explanation here is a suspicion that this one company is bent on retaining complete ownership of OO.o, as it's share of contribution decreases, and that that is deeply unhealthy and unjust (nevermind deterring other contributors). Anyhow, from subsequent actions it seems that suspicion was strongly vindicated:
• In categorically rejecting this simple and moderate progression to a more balanced ownership structure Sun obviously strongly defended it's demand to continue owning everything, even as it's proportion of contribution shrinks. Sun seems not content to own just it's own code (and changes to that), but wants to own everything. Furthermore, it appears to suggest (on the basis of its various special positions in OO.o ?), that this cannot be changed; it is also interesting to hear that all Sun Open Source projects are like this.
• Subsequently Sun made an offer to distribute the solver as a separate plugin. If Sun (or others) want to provide the solver as a plugin, they have all the rights they need (as has anyone else), as indeed they have all the rights to ship it as part of OO.o itself (under the LGPL), and even to ship it in StarOffice - under the LGPL. As has been said before, we're eager to see the solver (etc.) as part of OO.o.
• So - finally we have the re-statement of the status-quo from Mathias: as if this is an immutable law of gravity:

  It was always absolutely clear from the very beginning of Kohei's work and it was reinforced several weeks ago that the Kohei Solver will not get into the OOo code base without a JCA.

• It has never been clear that Sun's demand for total ownership (and hence ultimate control) would continue indefinately. Indeed quite the opposite, we have been promised a foundation from day one. Unfortunately it seems to be the case that there will be no re-examination of the ownership structure; ie. just re-stating the problem.
• Last week, Sun took the steamroller approach of reinforcing it's demands by decided that instead of making the solver a plugin itself (or whatever fudge it could construct), it would start re-implementing it from scratch. At that time, of course we started pointing people to http://go-oo.org/.
• Then, interestingly, later in the week Jim Parkinson basically re-stated Sun's position, though it seems there will be some welcome consultation on it. A major thrust of his blog is a proposed move to the SCA - whose only practical purpose is to strengthen Sun's ownership rights with a stronger copyright assignment; but back to Mathias:

  To sum up: the decision whether the Kohei solver or any other of the components Novell holds back will be contributed to OOo or not is a decision of Novell, not of anybody else.

• The JCA (or SCA) is not an immutable law, it is not necessary to assign everything to Sun to achieve any of the worthy stated aims of defending the license, re-licensing, etc. The JCA is not the very basis of civilisation, without which nothing can exist: an eternal tradition handed down from the elders, beyond question, for-your-own-good, etc. etc. Instead it seems to me an unbalanced control structure that retards OO.o's growth, and requires changing. It could easily be changed tommorrow by Sun. Switching to a more just and reasonable model is emminently sensible - though of course it is hard to imagine a King becoming a radical Republican.
• Finally, I look forward to the result of Jim's first Advisory Board meeting; and applaud his commitment that Sun is steadfastly behind a strong, transparent and fair community process. I am really looking forward to seeing that arrive.

• In the area of governance, I'll suspend judgement on a new Community Advisory Group, perhaps it'll be good, lets see.
• In the are of licensing - again, we see something that sounds wonderful, Jim writes: (my emphasis)

  This SCA goes a long way in addressing a variety of concerns with the current agreement. The most community friendly aspect of moving to the SCA is the inclusion of language stating that any contribution licensed out by Sun will also be licensed under an OSI or FSF approved license.

  So - lets look at the most community friendly piece, in this carefully reviewed document; is it so ? does it really meet Simon's claim "... so that proprietary-only forks are impossible.". It's good to link to Sun's FAQ but what about reading the actual agreement text. Lets start with clause 1 (IANAL etc. etc.):

  1. "Contribution" means any source code, object code, patch, tool, sample, graphic, specification, manual, documentation, or any other material posted or submitted by You to a Project.

  So far so simple, (and AFAICS an improvement on the JCA, it removes the unclear delivery / acceptance language). What about clause 2 (my emphasis):

  2. You hereby assign to Sun joint ownership in all worldwide common law and statutory rights associated with the copyrights, copyright applications and copyright registrations in Your Contribution. You understand that (i) this Agreement may be submitted by Sun to register a copyright in Your Contribution, and (ii) Sun may exercise all rights as a copyright owner of Your Contribution, including enforcement against infringers. You hereby grant to Sun, to the extent that the foregoing assignment is or becomes void, ineffective or unenforceable, a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under such copyrights, including sublicensing those rights to third parties through multiple tiers of sublicensees or other licensing mechanisms at Sun's option. Whether by assignment or license, both parties to this Agreement shall be able to do all such things in relation to Your Contribution as if each of us respectively were the sole owners of the copyrights therein. Neither party has any duty whatsoever to consult with, obtain the consent of, pay or render an accounting to the other party for any use or distribution of a Contribution or derivative work thereof. To the extent allowable under applicable local laws and copyright conventions, You agree never to assert against Sun or its licensees or transferees any moral rights in Your Contribution. Any Contribution that Sun subsequently makes available under any license will also be made available under a suitable FSF- or OSI-approved license.

  Well there it is; I guess what you would expect in a joint copyright assignment - though comparing to the JCA, the 'much improved' nature seems to revolve mostly around: "... several layers of agreement, so that if one proves to be unenforceable in some jurisdiction, there are other layers ..." (Simon Phipps), ie. it is longer and stronger.
• So - what about "The most community friendly ..." piece of this stronger assignment of rights to Sun ? lets look at that final sentence, in-lining & special casing the hacker's interest from clause 1 above:

  Any Contribution [ any source code submitted by You to a Project ] that Sun subsequently makes available under any license will also be made available under a suitable FSF- or OSI-approved license.

  So ... Sun covenants to make your (own) code submission available under an FSF/OSI approved license. I guess that is good: but since you already submitted your source code under such a license how does that help re-assure the contributor ? Again, it seems to me that this requirement is fully satisfied simply by a public archive of contributed patches, and does nothing at all to stop proprietary forks. At best, the commitment is slightly easier to fulfill if Sun chooses an FSF/OSI approved license for a project.
• Then again, IANAL, and must be mis-understanding this somehow, perhaps some kindly lawyer with a ministry to the bewildered can help me out. So - Jim asked for comments, my comment is: I'm confused - why is this so good, and who is it good for ?

    // Unless you do this, obviously you don't deserve to have anything work
    rtl::OString aCfg( "CFG_INIFILE=" +
                       rtl::OUStringToOString( curWd, RTL_TEXTENCODING_UTF8 ) +
                       "/configmgrrc" );
    fprintf (stderr, "Env '%s'\n", aCfg.getStr());
    putenv( (char *)aCfg.getStr() );

• Community Norms: it's great to hold up Apache, as a community norm; I'd love to see OO.o on that template: a vendor neutral, level playing field for all to contribute, and look: there is a very wide & dynamic base of contributors. What about all those eclectic ownership situations, where there is no single owner - those seem quite norm-al too. [Update 2012-05-31 - if politics is the art of the possible, then wresting views from the deep past and applying them today is the art of misleading people.]
• Contributor Agreements: - again, the analogy between the FSF and Sun as good stewards of software ownership is a huge stretch. One is an incredibly dedicated champion of software Freedom; and the other is a for-profit company. It is easy to imagine situations where Sun's duty to shareholders mandates them acting to harm OO.o. And it's particularly easy to believe it, given Sun's rejection of code only on the grounds of wanting to retain complete ownership.
• Non-surrender of copyright: - as I said yesterday, it all sounds nice - until any 2nd entity commits a few lines to the code, then the only rights holder is Sun.
• Defending the copyright: - IANAL, and horribly inexpert in this area, so forgive my rambling. I think Danese blogged in 2005 with this line of reasoning (though last I heard she was a staunch advocate of a foundation for OO.o). Is it really true ? Does Sun need to own everything so it can defend everything ? It seems rather convenient to assert that "The reason all the little guys have to assign rights to this big corporation is only so it can defend your rights", what if you want someone else to defend your rights, or do it yourself ? Also, how can you know that Sun hasn't licensed your code to this supposed infringer anyhow under some secret terms ? What about this (apparent) 51% rule ? it sounds nonsensical to me: if I copy Windows and Linux and OO.o onto a million DVDs and sell them - am I immune from copyright infringement law-suits, because no 1 company owns >51% of the thing, that would be extraordinary, is it so ?
• open source covenant: - what Simon says sounds really great:

  "There is an "open source covenant" - Sun promises that any contributions that get used will always remain as Free software wherever else they may end up, so that proprietary-only forks are impossible."

  but is that really what the new sca (do read it!) actually says ? [ not that OO.o actually uses it ] or am I missing something, is it this clause:

  Any Contribution that Sun subsequently makes available under any license will also be made available under a suitable FSF- or OSI-approved license.

  surely this is fulfilled just by having your 'Contribution' (defined term) in a Sun funded Revision Control System: ie. it safeguards your right to always get your own code back again (much like a backup tape). I really don't see how that makes proprietary only forks impossible - I must be missing something: what ?

• This is hardly a fork - and it's not even something very new in practical terms. As I said very clearly, we're still contributing the majority of our work to Sun, (and hence OO.o) under the JCA, and will continue doing so for the bits that touch their code. Indeed, right after I commit this yast2-gtk thing I'm going to get on with un-stalling my up-stream configmgr re-factor / speedup work, (actually a substantial LOC reduction, for those that like to count such things). So, there is simply no walking away from OO.o here, indeed why would we ?
• http://go-oo.org/ has been around for 5+ years, and despite a new & prettier web-site, simply continues a long tradition of pragmatic workarounds for various sub-optimal situations in OO.o. This is only one of tens of different OO.o variants out there: from StarOffice, RedOffice, Symphony to every linux distro I'm aware of that ships a custom version of OO.o, then of course there are tons of local variants, and individuals re-building & brand it in various ways.
• Wrt. copyright assignment, yes it's good to keep unified copyright assignment for (hopefully extremely rare) changes of Free software license etc. The problem lies not with the license, but the idea that a single company, with it's own agenda, having set itself up as the sole owner of an open source project, will then always act in that project's best interest. That just seems unrealistic, and the bigger the company - IMHO - the less likely it is. Now - a meritocratically constituted foundation, to which all code / translation etc. contributors belonged, with some truly representative governance - I'd love to belong to something like that & assign my rights to it.
• Another (possible) benefit from unified copyright assignment would be defending the copyright in court; again that is something a non-profit (like the FSF) has done in the past, and is presumably handled even in totally eclectic ownership structures eg. the Linux Kernel. And of course, OO.o already includes non-Sun-owned LGPL code.

Why choose terms you won't accept ?

Very disappointed to read Kohei's blog. Sun re-writing a contributor's code because they refuse to accept the licensing terms they give to other people: the LGPL; saddening. Sun chooses the licensing for OO.o; why choose a license they won't accept themselves ?

To step back a bit, it's worth understanding how Novell now contributes to OO.o. Clearly, we recognise & salute Sun's huge investment here over many years, and for all our changes to the core (> 50% of our work) we assign rights to Sun outright, and plan to carry on doing so as we labour to improve up-stream OO.o. We work closely with Sun's (excellent) engineers on joint development projects such as OpenXML import, VBA interop, core application features, re-factoring old code etc. To put it another way - we know Sun re-licenses this code as proprietary software, for it's own advantage, and we like our friends to be able to eat. Novell even uses a similar structure in two other very limited scenarios: for a tiny fraction of Mono, and for evolution.

What we don't like is the insistence that all and any contributed code, shipped at OpenOffice.org must end up being owned by Sun. In this case, the solver is a nicely separated, individual shared library UNO component and completely de-coupled from OO.o. I'm personally a fan of the LGPL, and OO.o (and StarOffice) contains lots of non-Sun owned modules including several LGPL modules, in it's core: eg. Daniel Velliard's nice libxml2 library. Due to static linking, there is even pure LGPL code floating outside the 'external' project. So - why is Kohei's nicely separated, working, specified, UNO component not acceptable purely under the project's license: the LGPL ?

How to offend developers

If OpenOffice was blessed (like other more sensibly structured projects) with a large, diverse and healthy developer-base, then perhaps we could expect to go around rejecting big chunks of code, offending developers and driving away potential contributors. To do this solely in order for Sun to retain total ownership of the code-base (and even loosely coupled components) - seems rather a betrayal of it's self-appointed stewardship role wrt. OO.o code ownership (under the JCA).

Then of course we have the announcement of the duplication itself (last comment in the issue), (though it was announced at OOoCon too), some nice myths: the "shared ownership" myth showing up in the solver integration

Stefan Taxhet wrote:
    Kohei, we would be happy to help you with the integration of
    your contribution in the main code base following the project
    guidelines. This implies shared ownership and licensing under LGPL.

'shared ownership' sounds friendly doesn't it: unfortunately as soon as more than one legal entity touches a piece of code, the only owner of the complete work becomes Sun: so not that 'shared'. Thus we can summarise this as: Allow Sun to re-license your code as proprietary software, or you can't be part of 'Open'Office.

    We are confident that this is the way the collaboration can
    do well with the best support from all participants.

What does that mean ? the best form of collaboration is where the weaker party assigns all their rights to the stronger ? Surely Sun is aware of the effect that this sort of decision has on potential contributors both corporate and individual. I for one, having (foolishly) championed encouraging people to sign the JCA at many conferences, am only too aware of how many clueful developers politely refuse, nevermind corporations.

    As this seems not to be an option for you we start to implement
a solution within the spreadsheet project.

There already is a fully implemented solution within the spreadsheet project, it's Kohei's solver, it even has a specification, it works, and it is there now. There is only one substantive issue: Sun doesn't own it.

    "You are welcome to join this effort."

Incredibly condescending to inviting Kohei to re-join his own project, this time as an unpaid Sun employee, but a kind thought ?

Summary

Sun is throwing away many months of Kohei's life, I surmise, because it knowingly asks others to accept a license, it will not itself accept. It insists on refusing contributions licensed under the project's own license.

Of course there are other projects that demand total copyright assignment, and given a choice of that vs. proprietary software it's clearly better to have Free software. However these projects tend not to produce a wide base of contributors, something that OO.o for the success of the Linux desktop desperately needs (oh and they tend not to call their projects "Open"Foo).

Copyright assignment can actually be useful, when you want to change licensing (though was not needed for dropping SISSL). If the primary goal of ownership is to allow (hopefully infrequent) licensing changes, surely having a sensibly structured non-profit to allow that, rather than a for-profit corporation would safeguard better governance.

Ultimately, it seems to me the current setup is not a winning, open approach, but a dangerous situation that hobbles OpenOffice.org, and leaves us in a bind. What can be done with our (un-acceptable) code ? (apart from rampant appeasement). Unfortunately the situation simply cannot be changed; and Sun totally dominates the whole OO.o process. Hearing yet again the rational that it must be this way, because it always has been this way is really not that satisfying either.

A way out ?

For many years, there has been a collaboration among Linux distributions (and others) to maintain a patch set for OO.o, including all those features & fixes that for reasons of time, process problems etc. have not yet made their way into OO.o (stalled in the bug tracker eg.).

Our aim with ooo-build has been to slowly work at evaporating this patch set away, by increasing the pace of up-streaming, contributing the core changes to Sun, and thus OO.o; and of course this is no set-back to continuing to get as many as possible of the core fixes included into Sun's OpenOffice version.

Regrettably though, it appears that some of these things can never go up-stream, as Sun refuses to accept them. Thus, it seems the best approach is to continue working where we can with Sun on OO.o, (helping them eat by improving their core) - while simultaneously providing our rejected features directly to users somehow.

Of course, this is not a new thing, we've always distributed a custom flavour of OO.o derived from ooo-build, as have many other Linux distributions, but recently, with the new SuSE build service and a (finally) updated web-site, we hope to be able to make development versions more widely available (including on Win32) at http://go-oo.org; you can grab Kohei's solver there today.

git clone http://people.gnome.org/~michael/git/iogrind.git
./autogen.sh && make install
./ext2dump /dev/sda1 /path/to/wherever > wherever.xml
fsview wherever.xml # beware of the monster bugs...

• "A great example of a stride in strategy" & user-friendliness ... would be for OO.o (writer?) to add a feature that noticed if the user would be better off using a DTP app and recommended Scribus instead. Apparently "In the open source world, you loose nothing by advertising somebody else's product..." - really !?
• Most problematic for Louis was (apparently) Novell subsidising a river-boat last year at OOoCon Lyon with meal & champagne. Incidentally we tried to do a similar (wrong?) thing this year but ran into problems... "Rather than a junket, perhaps the money could be better spent by sponsor companies on, for example **training project managers how to work in a more non-hierarchical fashion**" - one has to wonder: which project managers ? and who introduced all the unnecessary (& often dysfunctional) hierarchy we see in OO.o today ?
• Apparently "some companies don't really act as a sponsor in a true sense - they're prepared to contribute resources by supplying people to work on areas of programming ... and don't really work with the non-developer community" - well it's true: we hack on things that we think are interesting & useful to our customers & wrt. growing OO.o, and we invest ~nothing in non-developers. It seems clear (at least to me), that to improve OO.o - we need a lot less talking, and a lot more coding.
• "It would be great to have companies like Novell working more fully with the community, and not just in this market heavy fashion. Novell sponsors OOoCon, which is great, but rather than a barge cruise, using that money to help with QA, localisation and training etc. would see a better return for both Novell and the community as a whole." - some sage advice for sure. I mean, why sponsor a time for OO.o contributors to relax & talk (as a thank-you present for all the hard work they have done in the year) - when instead we could fund a fraction of an extra QA person ? oh & perhaps eat gruel to save money for critical project-manager training ?
• Then we move on to the vexing ethical concerns surrounding the sponsoring of events, we have "How much does it cost to buy the interest of the developer ?" - in general my feeling is approximately the cost of their salary. If anyone feels obliged to be nice to Novell on account of free beer, please don't be. Louis is at least correct to be un-fazed himself. I certainly don't feel indebted to VA, Google, IBM, Sun, Intel, Microsoft, and many others whose hospitality I've enjoyed over the years. Clearly the hope is not to buy people off, but instead to build community by putting people in a single boat, with some beers & encouraging them to talk to each other. From a stark hard-nosed perspective, I would try to persuade management that if we build a more fun & friendly community, Novell benefits via. a better product, though there is some brand, product awareness & feel-good factor too.
• Anyway, it's refreshing to know that the hard issues of the day in OO.o lie, not where I think they are: in the code, it's stewardship, and development: but instead in the ethics of accepting unwanted & unconditional hospitality. Cheers.

• Firstly - welcome, this is an amazing day for both IBM and OO.o. As something Novell has worked hard at (unfortunately behind the scenes) for many months, it's great to see this come to fruition finally.
• Louis Suarez Potts famously re-assured IBM (Don) in Koper that no-one in the community thinks not-releasing your OO.o code-changes is anti-social (or words to that effect). As a person who had spent some time hammering Don on this topic the night before, I was appalled. So I'm happy now to enthusiastically applaud IBM for doing the right thing: releasing all their changes & contributing them to OO.o. It's a great sight to see IBM step out of the proprietary swamp into a world of Free Office Software: following Sun's lead some years ago with OO.o.
• Go IBM ! It takes a lot of courage to start assigning all your code ownership to a competitor. My hope is that as more substantial contributors join OO.o, we will be in a stronger position to make this a truly open project, with meritocratic leadership and ownership (like ~all other successful, open communities).
• Speaking of ownership, here is a trivial spot the imbalance competition (some numbers approximate), just focusing on developers (as of the new world): if we add community translator head-count etc. of course Sun would be swamped numerically (and trying roughly to convert a number of part-time community developers into a guesstimated ~10 full-time equivalents):
  
  
  
  
• Question for Sun mgmt: at what fraction of the community will Sun re-consider it's demand for ownership of the entirity of OO.o ?
• Anyhow, welcome IBM !, I'm glad to have you involved in OO.o, and I look forward to working with you guys to try to make OO.o a project with lower barriers to entry, that people and companes can easily join; oh, and preferably one that is fun to hack on. Lets (finally) start to make OO.o rock.

if (ptr != NULL && ptr->getTribool())

if ( logic::tribool::operator&& ( ptr != NULL, ptr->getTribool() ) )

Nevertheless, a study from Rutgers University entitled "The State of Our Unions: The Social Health of Marriage in America", concludes that the institution of marriage is continuing to weaken, with a smaller portion of the population getting married than at any other time in our nation's history. In fact, since 1970 the rate of marriage has declined by one third. Perhaps even more worrisome is the discovery that fewer married couples than in any previous study report being 'very happy' in their marriage. What makes this level of unhappiness surprising is that since 1969, when no-fault divorce was instituted, the rate of divorce has tripled. The population of married persons has been reduced by a vast number of unhappy marriages, and yet those who are still married are less happy than ever.

• wrt. dating of the flood: only 1 piece of biblical evidence: genealogy - Gen 11 Noah to Abraham: 10 generations. Abraham generally agreed ~2000BC. Add Gen 11: ~2400BC - a possibility: assuming the genealogy is exhaustive & complete.
• Digs at Ur in S. Mesopotamia, initially excited Christian world: found siltation layer: right at spot - 2400BC: little/thin layer. Doesn't correspond with adjacent cities. 1000 years before - big siltation layer: 20feet thick.
• Leads one to suspect - genealogies highly compressed Matthew 1:1 Jesus, son of David, son of Abraham - covers 2000 years. Can't impose our cultural preference for exhaustiveness on the text. Several other examples Luke 3 has Cainan before Shela cf. Gen 11:12 'became the father of' etc.
• In conclusion, cannot safely deduce much except, can't possibly be later than 2400BC. Perhaps much earlier, vast amounts of time ? time of last ice-age 50kBC perhaps ?
• Sir Leonard Woolley - dug at other cities - no corresponded floods at other cities at same dates; even for the 20foot strata: big flood-plain of Tigris / Euphrates.
• Other issues: Jericho - archeologists: uninterrupted occupation there, back to 7000BC, no evidence of a flood at any point. Bible-believeing, sincere, careful archaeologists - pay attention, say flood at least 7000BC. Gordon's guess: 50k BC, it's a free country, anyone can guess. Time before anyone migrated to Australia, or to the Americas, Brazil ~30k BC.
• How extensive - less dogmatic: more honest, what bible actually says. One thing non-negotiable: everyone killed, all mankind wiped out - for sure. Does that mean - the flood-waters innundated Antartica ? necessary to conclude, entire sphere - if people not living there yet.
• Text calls - covering the 'earth' - hebrew word: 'land' / 'region'. Similar passage, later in Gen 41 And all the countries came to Egypt to buy grain from Joseph, because the famine was severe in all the world. No bible-believers postulate the Eskimos or Australians showing up: context matters. "World War II" eg. : tons of nations not involved; can't be sure from the text.
• Also, practical problems: worth acknowledging, becuase Christians know an enemy that is a deciever so cultivate a critical mind: examine the facts. Difficulties.
• Could every animal fit in the ark plus food for a year ? How did they get there ? did the Marsupials swim the Indian ocean (if so, why bother with an ark ?), and did they all swim back only to Australia afterwards ? What about the fresh-water fish ? was there an acquarium on-board ?
• Evidence of the whole Bible: another biblial text - a parallel description of creation talking of the primeval waters says of creation You set a boundary they cannot cross; never again will they cover the earth.
• God was angry at people, not Pandas. Further evidence: it seems to be an eye-witness account: Noah sent out dove, it could not find a place to set it's feet. Did Noah's Dove circumnavigate the globe ? checked Antartica / Everest ? seems unlikely.
• On the other hand - clearly, a vast, unprecedented, universal flood. Geological evidence - inconclusive, nothing more recent than 7000BC, possibly earlier. Some interest: a Columbia University study on the Black Sea sees a 60k square mile area innundated in a matter of months for example.
• Was there a flood ? you bet there was, let God be true & every man a liar. Not only the testimony of scripture but external corroboration too. No legend more universally attested than the legend of a flood that wiped out all of mankind before the birth of history: 300 narritives, Persians, Indians, Chinese, Japanese, American Indians, Australians, Greeks, Egyptians, Babylonians, Sumerians. etc. vast literature. Some of them - hallmarks of 2ndary invention: missionaries got there before the anthropologists Earliest accounts: written in ancient times: remarkably parallel to biblical account.
• Commonality - all other accounts, blame God: it's his fault: capricious, or annoyed - the human vermin make too much noise etc. Not so the Bible, Gen 6:2 - biggest foretaste of final judgement yet to come.
• Why ? man was destroying the value of life, and trashing the value of marriage: Lamech does both. Luke 17: "Just as it was in the days of Noah, so also will it be in the days of the Son of Man. People were eating, drinking, marrying and being given in marriage up to the day Noah entered the ark. Then the flood came and destroyed them all."
• Gensis 6 - people corrupt, violence: people imposing their will on one another, explotation - it's divorcing your wife, because she is inconveient: provokes God. Rampant sexual immorality - offends God.
• There were many in Noah's day this is it, grab all we can get or What I sow, I don't necessarily have to reap. Did I live my life 'without regrets ?' The only reason so many have a clear concience is that they have a lousy memory; forgotten grevious harm done to fellow man. A personal God, takes personally our offences.
• Ironic twist - men become their own 'sons of God', and God does the repenting: repented the Lord that he had made man on the earth His heart was filled with pain Gen 6:6. It grieves God, he repents - and takes back the gift of life.
• God's patience is no evidence of indifference: waters of baptism an echo of the flood: 1 Peter. Jesus' baptism similarities: God echoed what he said of Naoh with whom I'm well pleased, the Holy Spirit as a dove - returning to the ark: place of safety in the flood - hide in Christ.
• The Ark - not a boat: no bow, stern, rudder, no oars, no sail. A box, a temple - tripartite structure: same shape, virtually same dimensions: a temple - clean & unclean separated. Jesus' body also a temple of the Holy Spirit etc.
• Building an ark 100 years before the flood looks like a waste of time 2 Peter 3 they deliberately forget ... the world of that time was deluged & destroyed do not forget the Lord is patient not wanting anyone to perish, but all to come to repentance.

For our specific purposes we have computers that cannot have their equipment changed out (they're launched satellites). As the hardware has aged, some memory banks have developed address ranges that are bad. However, we run in a memory constrained environment, so we can't just ignore massive chunks of memory.

Sampling

• First separate all time into 1/2 seek time intervals (cf. H. Nyqist), ie. ~5ms intervals.
• in each interval track & log program behavior:
• all explicit I/O syscalls: eg. open/read/write/stat etc.
• track all implicit I/O: 1st time writes to new pages, touches of mmapped files (code & data).
• generate a log-file with filename / offset / size & stack-trace entries (elide lots of call traces across this interval).

Processing / visualisation

• a standard disk I/O latency simulator apparently there are a lot of these around the place.
• simple (deterministic, but statistical?) filesystem model (to turn paths to block numbers).
• noddy swap / LRU page replacement algorithm.
• simple page-cache / inode / dentry cache simulation.
• mindless [ and deterministic ] process scheduler.

Impact

So - of course the simulations don't have to be particularly advanced, or faithful to the O/S to give interesting results I think: much in the way that callgrind's 'cycle estimation' is a helpful guesstimate. That's important, as while the valgrind piece is hard to write, creating super-accurate simulators of kernel behavior is rather harder.

It is my contention though, that cold-start (and hence login time, boot time etc.) remain such untractible problems due to a lack of profiling tools for unexpected I/O behavior: particularly excessive seeking, and/or just reading too much data. Without tools to measure this - and particularly to be able to repeatably (and ~instantly) profile different data sets, with different (kernel) algorithms would make a huge difference.

Though it is indeed a KDE program, KCachegrind rocks my world, integrating with that beasty, and allowing the profiling to be tweaked eg. having a drop-down selection of: "aggregate I/O latency", "explicit I/O latency", "page dirties", "I/O bandwidth" etc. would be wonderful, also some model parameters to tweak: a "system memory" spin-button, a coarse disk characteristic: "Laptop" vs. "Desktop", a filesytem button: "ext3" vs. "ReiserFS" etc. etc.

typedef struct {
    int ref;
    int len;
    const wchar_t buffer[4];
} Str;
#define DECL_STR(a) \
    ((Str *)(&((const struct { int r; int l; const wchar_t b[strlen(a) + 1]; } ) { (1<<30)+1, strlen(a), L##a })))
...
printStr(DECL_STR("Foo"));

2007-01-07: Sunday

2007-01-06: Saturday

2007-01-05: Friday

2007-01-04: Thursday

2007-01-03: Wednesday

2007-01-02: Tuesday

2007-01-01: Monday

My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.