and of course the monster odg file so far (YMMV - re-factoring bit-rots such things over time etc.)
Stuff Michael Meeks is doing |
This is my (in)activity log. You might like to visit my employer Novell which is an amazing company, and also Dell who in days of yore provided me with a free laptop for Gnome development / conferences. Also if you have the time to read this sort of stuff you could enlighten yourself by going to Unraveling Wittgenstein's net or if you are feeling objectionable perhaps here. You can also burn useful hacking time by having a look at the logs from my Novell/GNOME friends:
The Alan Cox (en) Federico Mena Quintero Nat Friedman Miguel de Icaza George Lebl Planet-Gnome
2008-05-17/usr/src/packages/BUILD
and then unpacked SOURCES/*.tar.bz2 poked Stefan & Petr.
javaldx. The purpose of javaldx is to
(cunningly) grope your system - to look for performance-enhancing
java goodness: here are some stats:
| syscalls | 182000 |
|---|---|
| of which lstat64's | 161000 | normal (warm) start | 0.74 secs | under strace | 11.7 secs |
| strace log size | 17Mb |
/usr, 14k of /usr/lib, 13k of
/home etc. sigh. Perhaps the frenzy is just revenge for
not having any java on the live-CD system.
sudo; su - prompts
for a non-obvious password; interestingly vs. openSUSE's 11.0' LiveCD
there is no OpenOffice included; odd. Interesting to poke at baobab
to see the size breakdown of the live-cd - odd to have 130Mb of
fonts included, and nothing much to use them; Solaris suffers from
the gconf.xml.defaults malaise too - of ramming tons of translations
into a single file: when will the world stop doing this: 50Mb of
irrelevance ?
lzma-alpha-devel and
deltarpm on my old server system to make an applydeltaiso
that can operate on the new openSUSE ISOs: failed, bother. Time to upgrade
that system to an upgradeable system.
At this point you may be asking, "How about the important tasks at the top of the list, that one never does?" Admittedly, there is a potential problem here.As a perennial procrastinator, this is pure gold: the brief paper on perfectionsm, also invaluable: Philosophers' - who would be without them ?
zypper dup - still unreasonably pleased by it's general
sexiness, apparently born of long suffering.
zypper dup working so nicely.
svn://svn.valgrind.org/valgrind/branches/OTRACK_BY_INSTRUMENTATION
work that can pin-point long after the fact, where the dangerous
uninitialized memory that you branch on was allocated & thus give
much faster bug location.
dbus-daemon-launch-helper appears not to launch anything;
apparently a 'security' feature, bother.
svn: This client is too old to work with working
copy '.'; please get a newer Subversion client everywhere; if only
there were some 'downgrade' feature.
NetworkManager-novellvpn-gnome, which I hadn't
realised is in the public channel these days (making life unfeasibly easy).
/dev/disk/by-id/scsi-SATA<essay here>-part1etc.
Eventually installed 11.0 Alpha2 and set off an update to factory.
http://www.gnome.org/~michael/git/dbind.git/
that allows more friendly use of structured types, for a method of type:
struct TeamName { string id; string name; string url; } array>TeamName< GetTeamList();typedef struct { char *name, *id, *url; } TeamSpace;
...
GPtrArray *spaces;
dbind_context_method_call (ctx, NULL, DESKICE_PATH, DESKICE_NAMESPACE,
"GetTeamList", &error,
"=>a(sss)", &spaces);
for (i = 0; i < spaces->len; i++) {
TeamSpace *space = spaces->pdata[i];
fprintf (stderr, "\t%d: %s, %s, %s\n", i, space->name, space->id, space->url);
}
#define g_return_if_fail(expr) G_STMT_START{ (void)0; }G_STMT_END #define g_return_if_fail(expr) G_STMT_START{ if (G_UNLIKELY (!(expr))) return; }G_STMT_END "You shall not covet your neighbor's house. You shall not covet your neighbor's wife, or his manservant or maidservant, his ox or donkey, or anything that belongs to your neighbor."There are several simple points to make here:
That souls have no discriminating hue,
Alike important in their Maker's view;
That none are free from blemish since the fall,
And love divine has paid one price for all.
Sun didn't just make vague statements to me about OpenSolaris; they made promises about it being an open development project. That's the only way they could get someone like me to provide free labor for their benefit. Given Sun's recent track record on breaking promises, another one doesn't surprise me at all. ... Sun gave up its right to make arbitrary decisions regarding the phrase "OpenSolaris" as part of its public agreement with the community in the form of the Charter. ... Sun agreed that "OpenSolaris" would be governed by the community and yet has refused, in every step along the way, to cede any real control over the software produced or the way it is produced, ... Rather than be honest about it and restructure the community to correspond to this MySolaris style of over-the-wall development, Sun prefers to lie to the external community members while ignoring their input. Yes, Sun has the legal right to make that decision, just as it has a legal right to dissolve the charter and start over with a new governance model. The choices being made are NOT the problem. The problem is the way that the choices are being made WHILE, at the same time, portraying the project in public as a community-driven effort. ... Sun should move on, dissolve the charter that it currently ignores, and adopt the governing style of MySQL.
Sun is making decisions "for" the community with no regard to the membership or Governing Board ... Sun is holding all the keys and while I trust 99% of the Sun employees involved in the community, the fact remains that it would seem that none of them had a hand in this decision ... OpenSolaris as it was conceived by the community is a sham. ... we have open source but we don't have open development. Sun has done an admirable job with releasing code, but Sun's track history in the arena of open development efforts with the free software community has been abysmal ... the MySQL model, which I refer to as "glass house development", that is, you can look in at whats going on but you're not part of the action.
| task | before | after |
|---|---|---|
| pagein | 3.4sec 93Mb | 2.6sec 73Mb |
| soffice.bin | 1.2sec 10Mb | 2.7sec 23Mb |
| total | 4.6sec 103Mb | 5.3sec 96Mb |
fbCompositeCopyAreammx bother, more investigation later.
http://download.opensuse.org/repositories/home:/srinidhi:/evolution-unstable/openSUSE_10.3/i586/
and the Evo team are fixing bugs fast.
X -query foo to
work - gdm reports WARNING: gdm_xdmcp_handle_manage: Failed
to look up session id random-number - irritating in
the extreme.
| variant | startup bindings |
|---|---|
| current | 91300 |
| -Bsymbolic-functions | 63600 |
| -Bsym + vtrelocs | 58100 |
extern SVT_DLLPUBLIC sal_Char const SVTOOLS_CONSTASCII_DECL( sHTML_S_aacute, "aacute" );( sizeof "sHTML_S_" + sizeof (relocation) ) * ( num-references + 1 )
and we loose performance: 2400 unique named relocations, searched across 50+
shared libraries: ~0.8% of OO.o CPU time on startup. And all in the name of
efficiency. Unfortunately, the technique dates back to the dawn of
time, (in cvs history terms), so it's hard to discern the intention. I wonder
where else it's used.
Anyhow, the 'best' fix (to save the optimisation) is to export
one symbol, s_HTML_Strings that is an enumerated array of strings
#define sHTML_S_aacute s_HTML_Strings[eHTML_S_aAcute]
type
thing. But for now, some search/replace action is perhaps easier.
/proc/<pid>/mem
looks like just what you want, until you try to use it - you have to
pread the addresses out. Dug at
cryopid for some stealable code, before giving up. Presumably manual
fun and dump binary memory filename start_addr end_addr
in gdb is the best that can be done easily.
| variant | size | unique named relocs | fn / thunk unique named relocs |
|---|---|---|---|
| current | 10154324 | 10375 | 6650, 1718 |
| -Bsymbolic-functions | 10020556 | 3891 | 1404, 481 |
| -Bsym + vtrelocs | 9840180 | 2135 | 37, 0 |
echo "0" > /proc/sys/kernel/randomize_va_space.
Found I wasn't linking the new libsvx correctly, fixed that. Of
course the real benefit of vtrelocs is (having switched virtual
function calls to going via the relevant vtable) not exporting any
virtual symbols / thunks; but that's for the future.
--disable-bootstrap is the solution, nice.
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.Sad indeed. It is unusual to air such threats made in private, and of course it's sad for Sun to fund problems for itself with severance money (as has happened before). Having said that, clearly this is a highly unattractive action, taken (I hope) against Sun's better overall vision of open-ness. Anyhow - clearly there is some great scope here for making bold gestures of direction around open-ness & ownership in other large (productivity?) projects.
desktop_entry_load is (as expected) a huge chunk of the time,
and (due to applications dropping .desktop files erratically during install,
the directory is nice and scattered, such that the 'obvious' recursive
iteration over 'readdir' is pretty broken [ though interestingly for some
things like screensavers which install a big block of .desktop files, we
take almost no time ]: picture appended, patch to follow:
time touch ~/foo.txt -
11seconds real (eg.).
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.Clearly that cheap lead-alloy airframe was a great investment. Still none the wiser on how long it takes to write a (S)LOC though; 1000 LOC/week would be 2+minutes / line, which seems a lot, though unfortunately sending everyone on typing courses is not going to help; ho hum.
ENVCFLAGS=-Werror testing, some lack-of-assertion testing -
looks lovely; 'Ready for QA'.
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.
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.
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.
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.
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.
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.
// 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() );
rtl_bootstrap_set
which seems ideal for the task.
"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 ?
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 ?
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 ?
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.
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.