Stuff Michael Meeks is doing |
Older items: 2023: ( J F M A M J ), 2022: ( J F M A M J J A S O N D ), 2021, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
Devel::NYTProf for perl profiling; apparently that would be the way to go if the problems were not so (relatively) trivial to find - thanks lazyweb. qr// the regexps. Anyhow nice to achieve at least some hack no matter how small. -d:DProf instead which looks saner. Found and fixed some really dumb algorithm taking 10 seconds, ~25% faster, good - it's still amazing to me how slow perl regexps (even pre-compiled) can be. ln -sf /dev/stdout ~/.y2log - nice, leaving stderr for in-line custom fprintfs. Lunch. sudo zypper si OpenOffice_org-calc at least fetches the source now. gnome-web-photo is the culprit: as (in this case) randomly called by evolution to thumbnail an HTML attachment on a specific groupwise meeting request; thankfully managed to track it to the source instead of filing deranged "Groupwise kills firefox settings" type bug. $ gimp bootchart-with-1.png The program 'gimp' can be found in the following package: * gimp [ path: /usr/bin/gimp, repository: zypp (repo-oss) ] Try installing with: sudo zypper install gimp bash: gimp: command not found such prettiness makes me forget my sadness at not being able to (eg.) have a complete development toolchain on the Live-CD. sync() in umount conditional on actually having unmounted something, looks nice on the boot charts: sent off a patch. Filed various bugs, more mail poking. An auction's afoot (no pun intended) to see who we'll be partnering with us to integrate their businesses and brands into our binary product distribution - the possibilities are limitless: people tend to print those documents, fax them, copy them, project them (and I know this annoys my friends in the free software community, but branding allows us to invest more in OO.o community and features, from which everyone benefits).It looks like we can all look forward to more Sun (or other) brands across OO.o, and auctions (with presumably un-disclosed terms & payments) for product positioning inside OO.o (as well as Java). The piece about investing more in OO.o is a bit rich though, given the fact of their declining investment. As a corollary - Is success having a Sun watermark on every printed page ?. Another interesting aspect of this blog is how Java (and Java ISVs) are being used to drive MySQL adoption: seems reasonable; but what if you contribute to (or use) Java but don't like MySQL ? (perhaps preferring the better postgresql eg.) and don't want your support and use of Java to turn into support for MySQL: bad luck I guess.
sync() slowing down boot - of course, that just moves the problem to somewhere else in my case some umount -alt nfs,nfs4 call - but, presumably that can be fixed too in due course. Either way - calling sync when you just want to fsync a single file eg. /etc/mtab is somewhat anti-social anyway (surely). IMPLEMENTATIONS/ directory with the hundreds of components this is not good. Knocked up a patch. [Mark's] ... goal is to push the Ubuntu GUI up to the level of Apple's ... It's possible that sentiment has never been voiced in the history of GNU.Strange, I thought I heard this aspiration regularly, throughout GNOME development, and even by RMS back in the day and wow, reading that controversy - I yearn for the old days: "In short, I'm a huge believer in an open meritocracy that encourages bottom-up development instead of forcing top-down "standards." Like CDE." - there's still perhaps a lesson for OO.o there somewhere.
I hope that works out well for whomever happened to get dropped into sharing the same server as the heavy spreadsheet user. What about the web technologies ? - apparently this is not Silverlight only, though there seems to be an acknowledgement that if you want a version that performs well, you will need that, otherwise (reading between the lines) I suspect it's a lot of bitmaps, lag and server side rendering.Total amount of PC memory that Excel can use Old Limit: 1GB New Limit: Maximum allowed by Windows
The exact technology mix doesn't seem to be public yet, but the MS Office code-base is mythically large and twisty. Having said that they seem to have a Model/View separation clean-up underway, unless the live collaboration is some grisly hack. I strongly suspect, where claims of perfect visual fidelity (6:05 into the video) are made, that this is a StarPortal model, or perhaps even more basic - with EMF+ or even an RDP-like protocol being used with a -very- thin client, ie. a model akin to Ulteo's embedded-Java/VNC style setup.
Of course, this type of architecture is really great for getting apps onto the web fast, and sharing that code-base with the fat client, but ultimately can never allow dis-connected operation. Then again, for large complex applications I've never believed the "re-write everything in JavaScript with Gears" mantra (after all, we've not yet finished the re-write of everything into Java yet), and it seems (to me) an expensively lame solution to the simpler deployment problems the web is supposed to solve.~/.config/monitors.xml is worth backing up after getting it right (with xorg.conf). Apparently people are trying to stick 'forks' into each other (and in particular me) these days cf. Simon & Roy's noted enthusiasm for this. Apparently (particularly according to medieval, western, knife manufacturers everywhere) the fork is hell-spawn, not to mention economically damaging, particularly when bundled with rice. But, what is a fork ? Wikipedia's write-up is helpful but extremely broad.
Back in the day - I used Slackware Linux (cue nostalgia for antique hardware etc.) but now I read up on it, I seem to have been duped: Slackware seems to have been based on a fork of SLS! - I was cheated out of using the real thing. Worse than that, apparently SLS was forked again by that Ian Murdock guy into something called Debian. Sadly, since then, SLS appears to have gone the way of the "Save the Stegosaurus" campaign.
Of course - there are now hundreds of Linux Distributions, each with different choices built in, many with different packages. Of course, there is some nuance here - is Mandriva a fork of RedHat ? is Ubuntu a fork of Debian ? is Mepis a further fork of Ubuntu ? are these cycles of creative destruction: branching, tweaking, trail-blazing new directions, including new features, and/or failing and disappearing bad ? should we have a central planning committee wielding powerful legal tools to pro-actively stamp them out ? or are they a positive side-effect of open-ness: allowing bad ideas to be weeded out by survival-of-the-fittest ?What makes a fork ? Can a budding etymologist confirm the relation to the unix 'fork' system call ? If you use that, in a miracle of copy-on-write-ness; post fork, anything you change is not shared with the parent process ?
Why are linux distributions not generally seen as forks ? I hypothesise that the answer is primarily that development is (for the most part) not independent - distros work on the same underlying code, and (hopefully) contribute their changes back to the common underlying code-pool. Of course, they tend to put different branding on top, have different configuration settings, and often include packages specific to their own distribution, some of them (sadly) not Free software.
What about branching ? is cvs tag -b gnome-2-22 a fork ? do projects go forking themselves regularly as wikipedia suggests ? again, usually people don't call this a fork - it's a branch, and code changes go into both sides of the branch. What then about adding components to a package ? is writing a new out-of-tree kernel module a fork ? what if you give it to some of your friends ? Does this apply more broadly ? is open-sourcing Solaris creating a fork of the GNU/Linux stack - by replacing a key component with a duplicate ? or is that just duplication ? or is Linux itself a fork/ duplication of PrimevalNix and thus intrinsically bad ? does licensing matter ? is duplication for licensing reasons acceptable ? how about purely for ownership ?
David A. Wheeler's forking appendix (to his interesting paper) postulates intent here; is the intent to become a competing or replacement project ? Well, certainly I'd like go-oo to become, as long as Sun pointlessly excludes our features, a replacement distribution (NB. not fork) of OO.o to the one Sun controls: simply because I'd like to get this injustice addressed, but of course, I'd far prefer to have a single up-stream community controlled source for OO.o.
Re-applying this to the world of OO.o, lets look first at StarOffice - was that a fork of OO.o ? in the past when it included proprietary closed source pieces and custom tweaks, and clearly was intended to compete with OO.o, did Sun fork it's 'own' project ? or was that a commercial re-distribution of OO.o with bits added ? How about ooo-build / go-oo ? that includes plenty of patches that for one reason & another (mostly the pain threshold) are not yet up-stream, the snapshot looking far worse than it is, since many patches have already gone up-stream over the years. Of course go-oo also includes some pieces (mostly well separated) that Sun simply refuses to accept up-stream because it wants to own them. Does that make it a fork ? if so, who is to blame for any negative effect ?
Some issues are great for endless charged debate - to quote Yes Minister, The problem is all my facts are statistics, and all your statistics are facts. I (of course) pass on useful and relevant information; it is other people that gossip, I take a lively interest in my surroundings; it's the other people that are nosy etc. People can call go-oo a fork certainly, it's a convenient way of putting it in a box marked 'evil' without mature consideration - but perhaps for consistency they need to call rather a number of other things forks, putting us in good company. Personally, I think forking is sometimes justified, but is go-oo really a fork ? you decide. Whatever your answer, it is totally facile to insinuate that because we encourage people to work on go-oo, that none of their work will get into Sun's OO.o - some of it will (we hope), and we'd love Sun to take the components too, under the copy-left license of their choice.
paman - the pulseaudio thingit that lets you actually set the output volume level to a sane level (thus saving neck injury while trying to get the ear near the speakers). For some reason I keep forgetting it's name. Why the underlying device likes to have a really low level in the first place is beyond me. daemon/INTERNALS which is somewhat helpful, but these async, multi-process, intensive IPC designs are still hard to grok; bother. Is success measured in downloads, or up-loads? are bugs filed as good as bugs fixed? are volunteer marketers as valuable as volunteer developers? If we have lots of bugs filed and lots of volunteer management material is that success? is the pace of change important? Does successful QA exist to create process to slow and reject changes, or by accelerating inclusion of fixes improve quality? Is success having complete, up-to-date and detailed specifications for every feature? Is success getting everyone to slavishly obey laborious multi-step processes, before every commit? Alternatively does success come through attracting and empowering developers, who have such fun writing the code that they volunteer their life, allegiance and dreams to improve it?
I encourage people to download & use OpenOffice.org in one of it's derivatives. I'm pleased when people file bugs, help with the QA burden, promote the projet etc. However, in a Free Software project the primary production is developing and improving the software - ie. hacking. So the question is: how is OpenOffice.org doing in this area? Are we a success in attracting and retaining hackers? Is the project sufficiently fun to be involved in that lots of people actually want to be involved?
As we are finally on the brink of switching away from the creaking (22 years old) CVS (provided by Collab.net), to an improved Sun hosted Subversion (sadly not a DRCS) - Kohei and I created a set of scripts to crunch the raw RCS files as they go obsolete. They reveal an interesting picture.
As with any measurement task, we believe these numbers are fairly reasonable; and we try to make them meaningful. On the other hand perhaps there is some horrendous thinko in the analysis, bug reports appreciated. It'd also be nice to see if the internal Sun statistics match these.
Firstly - the data is dirty; since we're analysing RCS files; so - when files are moved to the binfilter, or even renamed they have been simply re-committed - causing huge commit spikes. Similarly license changes, header guard removals and various other automated clean-ups, or check-ins of external projects cause massive signal swamping spikes. We have made some (incomplete) attempts to eliminate a few of these. In recentish times all work happens on a CVS branch, which is later merged release engineers (who appear to have done ~50% of the commits themselves), so we filter their (invaluable) contribution out by account name (cf. rt's oloh score).
Secondly - another distorting factor is that we chart only lines added: in fact when you change a line it is flagged as an add and a remove; so the number is more correctly lines added or changed. This of course fails to capture some of the best hacking that is done: removing bloat, which should be a prioirity. In the Linux kernel case this metric also gives extra credit to bad citizens that dump large drivers packed with duplicated functionality, and worse it rewards cut & paste coding. I don't often agree with Bill Gates but:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.still at least the 'lines changed' facet should be helpful.
Thirdly - release cycles cause changes in contribution patterns, clearly frantic activity during feature development lapses into more bug-fixing later in the cycle. Thus we expect to see some sort of saw-shape effect.
Fourthly, working on OO.o is infernally difficult, getting code up-stream is extremely and unnecessarily painful - this results in many contributors leaving their code in patches attached to bugs in the issue tracker, and we make no account for these; these changes (if they are committed at all) would appear to be Sun commits. Thus it is possible that there is at least somewhat wider contribution than shown. Clearly we would hope that full-time contributors would tend to commit directly to CVS themselves.
This graph is more meaningless than it might first appear, the raw data still shows noise like individuals committing obvious sillies copying chunks of OO.o to the binfilter eg. To some extent it is further distorted by us trying to clean this up for the past couple of years before giving up:

So the data is not that useful. Is it more useful to look at an individual to see if they are contributing something? If we threshold the data we can at least approximate an activity metric / boolean. The graph below shows two developers - the Sun developer Niklas Nebel, and the Novell hacker Kohei Yoshida. Both work primarily on calc, and you can see the large bar when Kohei committed his solver to a branch at the end of 2006.

It seems clear that we can at least approximate activity with some thresholding. More interesting than this though, we can see a most curious thing. Despite Calc (apparently) being the relative weakness of OO.o, and Niklas being the maintainer of the calc core engine, and the calc "Project Lead" (with special voting privileges for the 'community' council), in fact he hasn't committed any real amount of code recently. That jumps out in the comparison with (vote-less) Kohei in the last six months. It is very sad indeed to all but loose Niklas from the project, though at least we'll see him at OOoCon. Verifying this counter-intuitive result with bonsai reveals the same picture.
Extending this metric to the entire project we see perhaps a more interesting picture. By thresholding contributions at one hundred lines of code added/changed per month, we can get a picture of the number of individuals committing code to OO.o. Why one hundred? why not? it's at least a sane floor. Clearly we get a metric that is very easy to game, but luckily that's hard to do retrospectively.

It is clear that the number of active contributors Sun brings to the project is continuing to shrink, which would be fine if this was being made up for by a matched increase in external contributors, sadly that seems not to be so. Splitting out just the external contributors we see some increase, but not enough:

Novell's up-stream contribution appears small in comparison with the fifteen engineers we have working on OO.o. This has perhaps two explanations: of course we continue to work on features that are apparently not welcome in Sun's build cf. the rejection of Kohei's solver late in 2007, and much of the rest of our work happens in ooo-build, personal git repositories, and is subsequently filed as patches in IZ.
So, it should be clear that OO.o is a profoundly sick project, and worse one that doesn't appear to be improving with age. But what does a real project look like that is alive? By patching Jonathon Corbet's gitdm I generated some similar activity statistics for the Linux kernel, another project of equivalent code size, and arguably complexity:

There are a number of points of comparison with the data pilot of active developers aggregated by affiliation for OO.o.
Similarities: both graphs show the release cycle. Spikes of activity at the start reducing to release. Linux' cycle is a loose 3 months, vs. OO.o's 6 months.
Differences: most obviously, magnitude and trend: OO.o peaked at around 70 active developers in late 2004 and is trending downwards, the Linux kernel is nearer 300 active developers and trending upwards. Time range - this is drastically reduced for the Linux kernel - down to the sheer volume of changes: eighteen months of Linux' changes bust calc's row limit, where OO.o hit only 15k rows thus far. Diversity: the linux graph omits an in-chart legend, this is a result of the 300+ organisations that actively contribute to Linux; interestingly, a good third of contribution to Linux comes from external (or un-affiliated) developers, but the rest comes from corporates. What is stopping corporations investing similarly in OO.o?Crude as they are - the statistics show a picture of slow disengagement by Sun, combined with a spectacular lack of growth in the developer community. In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux's recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective.
Does this matter? Of course, hugely ! Everyone that wants Free software to succeed on the desktop, needs to care about the true success of OpenOffice.org: it is a key piece here. Leaving the project to a single vendor to resource & carry will never bring us the gorgeous office suite that we need.
What can be done? I would argue that in order to kick-start the project, there is broadly a two step remedy:
Unfortunately, the chances of either of these points being addressed in full seem fairly remote - though, perhaps there will continue to be some grudging movement in these directions.
A half-hearted open-source strategy (or execution) that is not truly 'Open' runs a real risk of capturing the perceived business negatives of Free software: that people can copy your product for free, without capturing many of the advantages: that people help you develop it, and in doing so build a fantastic support and services market you can dominate. It's certainly possible to cruise along talking about all the marketing advantages of end-user communities, but in the end-game, without a focus on developers, and making OO.o truly fair and fun to contribute to - any amount of spin will not end up selling a dying horse.
Why is my bug not fixed? why is the UI still so unpleasant? why is performance still poor? why does it consume more memory than necessary? why is it getting slower to start? why? why? - the answer lies with developers: Will you help us make OpenOffice.org better? if so, probably the best place to get started is by playing with go-oo.org and getting in touch, please mail us.
Finally - we invite you to repeat the analysis, the raw spreadsheet data (for data-miners) is here: ooo-stats.ods linux-stats.ods and the RCS parsing scripts parse_rcs.py with dependants in that same directory.
~/.ssh/known_hosts file I should be doing ssh-keygen -R , which is a good point, though hopefully something I'll have to do a lot less of now. OpenOffice_org-libs-gui.src.rpm package (11Mb), and zypper got me another 46Mb of -devel package (we're working on shrinking that too). Realised I need to tweak /usr/lib/ooo3/solver/LinuxIntelEnv.Set.sh to add an /opt/icecream/bin to CC & CXX, then: sudo bash -l -c "/usr/bin/rpmbuild --eval '%define jobs 10' -ba SPECS/OpenOffice_org-libs-gui.spec" and bingo, it built for 10 minutes and died with some Java problem; bother (missing some package dep somehow). Luckily I had enough built to debug, and committed some deferred dependency generation speedup before hitting the gdb-is-not-working issue: filed that instead. no permission to create project ..., which is great. Apparently the latest osc needs --no-verify to build things, and flies more gracefully with su-wrapper = sudo in ~/.oscrc. ~/.ssh/known_hosts - which is hyper-irritating. Dear lazyweb, is there a good way to turn off such checking but only for a local sub-net ? Host 192.168.0.* UserKnownHostsFile=no StrictHostKeyChecking=nothanks.
const char *s you pass to it forever. | type | readings | average |
|---|---|---|
| with pagein | 4.160, 4.081, 3.987, 4.023 | 4.06 |
| without pagein | 4.311, 4.759, 4.379, 4.571 | 4.51 |
/usr/share/locale-bundle/en_GB/LC_MESSAGES/* an lsof on those shows an interesting picture. Strangely, when I log in. I only see less than a handful of translated strings on my desktop - surely we an do better here. Perhaps some LD_PRELOAD'ed gettext pre-cache might save some seeks. dbus-send doesn't instance - as reported in March, now affecting /usr/lib/pm-utils/sleep.d/10NetworkManager. NB. people using dbus-send must add --print-reply if they want to reliably send a message. git grep. Out to a nice Intel sponsored dinner in the evening - Intel knows how to throw a good party. /lib/modules/`uname -r`/build, and so on. Finally found the bug is fixed in HEAD systemtap anyway, filed a SUSE issue, sent off a trivial patch. Sadly when it runs, it does something -so- strange to my system that it terrifies me; will come back later. make %{?jobs:-j%jobs} is best handled with some rpmbuild --eval '%define jobs 8' -ba foo.spec than otherwise, sadly much googling, manual and code reading didn't make this at all obvious. We chose LiMo because it's a collaborative effort. It's not just one company runs the place. We like that. We like a collegial and collaborative effort, where there is no barrier to entry on the part of developers and, at the end of the day, there is no one entity that can say 'OK, here's how we were playing now. The rules are changed.' LiMo will be our preferred OS because of this openness.Whether sincere or not, I couldn't agree more. Give me a genuine, open, plural community any day over a single vendor dominated one.
$ ls -lR ~/.thumbnails | wc -l 12798 hmm. Apparently we shove all those into a hash_table in the slab too gnome-thumbnail.c (read_md5_dir) The company must learn to let go a little bit and let the open source ecology proceed naturally. In the short term, Sun might lose a little bit of advantage in the market, but long term, it is has a better shot at success.Start with OO.o: give us real, meritocratic governance and real (instead of sham) compromise on code ownership (as we have outlined & requested) - instead of trying mightily to avoid both issues while feigning 'Open'ness.
echo "Unpacking OO.o build tree - [ go and have some $DRINK ] ..." with a fully configurable: AC_ARG_WITH(drink, [ --with-drink The parameter is a favourite drink that unpack should advice you to take. Example: --with-drink=coffee], ,)- the joys of community; tweaked the spelling: 'advise' - thank goodness the default is still tea (for the UK), and not Coca-Cola. Chat with Rene.
echo t > /proc/sysrq-trigger a little but got no-where in the end. Well pleased with X / drm / radeonhd stability - in comparison with the proprietary drivers, I spent an hour SIGKILL'ing X, switching consoles, modprobe -r'ing, starting and killing compiz and so on, and the machine is still alive. R500 support requires a newer drm. - I actually read the drm readme, and discovered make install needs running in linux-core as well as the top-level (obviously). 
I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures. This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash.The solution is of course obvious: to give staggering amounts of highly parallel beefy hardware to an infinite number of free-software hackers. Failing that, CPU vendors could do a lot worse than invest a fortune in Julian's helgrind thread checker.

ftw glibc call - I wonder how efficient it's I/O is. 
1211970599.543457 poll({snip fd details}], 14, 186) = 1 1211970599.543928 gettimeofday({1211970599, 544334}, NULL) = 0 ie. we ask to sleep for 186us, and we get control back to call gettimeofday 471us later. Of course, quite why we are waking up -so- frequently, and reading ~20 bytes of samples, and going back to sleep for such a short time is unclear to me; 260 poll / recvmsg's per second - just to play a mp3; odd. Could it be that this is the solution ? Unfortunately esd works (apparently) perfectly on the same machine at a much more sedate 14 2k reads per second instead. http://www.go-oo.org/~michael/blog/index.atom. (gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb6eb21d7 in *__GI___poll (fds=0x8641990, nfds=6, timeout=599) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0xb554f6f2 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x08641990 in ?? () #4 0x00000006 in ?? () #5 0x00000257 in ?? () #6 0x08641990 in ?? () #7 0x00000006 in ?? () #8 0x00000000 in ?? ()And afterwards:
(gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb6eb21d7 in *__GI___poll (fds=0x8641990, nfds=6, timeout=599) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0xb554f6f2 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0xb554f9d8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0xb5b3d68d in ?? () from /usr/lib/ooo-2.0/program/libvclplug_gtk680li.so #5 0xb54f4751 in X11SalInstance::Yield () from /usr/lib/ooo-2.0/program/libvclplug_gen680li.so #6 0xb7e06cf1 in Application::Yield () from /usr/lib/ooo-2.0/program/libvcl680li.so #7 0xb7e06d3f in Application::Execute () from /usr/lib/ooo-2.0/program/libvcl680li.so #8 0x08071c53 in desktop::Desktop::Main () #9 0xb7e0a27e in ?? () from /usr/lib/ooo-2.0/program/libvcl680li.so #10 0xb7e0a41a in SVMain () from /usr/lib/ooo-2.0/program/libvcl680li.so #11 0x08066c60 in main ()Save your download bandwidth quota (and the planet too) by grabbing a new gdb for your OpenSUSE 11.0 from here.
"MS should build the extensions they need for interop on top of ODF"were actually sincere, or whether they now switch to an equally shrill albeit contradictory:
"They are evily embracing and extending our standard"Given the feature sub-set problem in ODF, can you have the embrace without the extend ? Of course, it is possible that MS (unlike Novell) have no real interest in improving the serious inadequacies around interop. in ODF, in which case their customers will just get upset:
"why does my document look different when I save as ODF, and re-load it in Word"Can you imagine the synthetic outrage that either of these will generate ? Then again, perhaps they will want to improve interop. in the standard, at which point we will inevitably quickly hit the:
or even
"Why, when I select ODF mode, do so many features disappear in the UI"
"This can't go into the standard because there is no implementation in OO.o [or perhaps the more sophisticated 'multiple implementations']"type argument, or will that be waived - in which case we will hit the:
"OO.o can't load & render it's native file format"chestnut - which of course has always been true of KOffice's ODF use and which we keep hearing re-iterated in various forms about Office 12 and OpenXML. Anyway - at the end of whatever "pick your own fight" session we're in for, when all the dazed, confused and exhausted pundits grind to a halt there are perhaps two lessons that will become obvious here:
www.gnome.org answers replies to queries rather differently depending on where they come from (apparently) - some people just get ECONNRESET almost immediately (perhaps a firewall issue). Of course, wget works from everywhere - here is the query it does: GET /~michael/blog/index.atom HTTP/1.0 User-Agent: Wget/1.11.1 Accept: */* Host: www.gnome.org Connection: Keep-Alivevs. the query the uber-powerful (etc.) feedparser code does (apparently due to some fun charset love:
GET /~michael/blog/index.atom HTTP/1.0 Host: www.gnome.org A-im: feed Accept-encoding: gzip, deflate Accept: application/atom+xml,application/rdf+xml,application/rss+xml,application/x-netcdf,application/xml;q=0.9,text/xml;q=0.2,*/*;q=0.1 User-agent: Planet go-oo +http://planet.go-oo.org/ Planet/2.0 +http://www.planetplanet.org UniversalFeedParser/4.1 +http://feedparser.org/Presumably the latter looks like a DDOS attack, but only from some IPs (perhaps go-oo.org has a dodgy 2nd hand Russian-Mafia-style IP address).
/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://people.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. 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.
Michael Meeks (michael.meeks@collabora.com)