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
x-carriage-lower) - a raft,
duct taped down, etc. Adhered to the tape beautifully - which then
bubbled off the surface - bother. Eventually got a fairly warped but
functioning carriage: nice.
mcompositor appears to render blackness, and
duihome does nought but a black-and white demo
app - odd.
CLUTTER_VBLANK=none is the
solution; now of course - I appreciate that no doubt this is to work
around a driver bug; but is it really sane to continue to wait whole
minutes for a vblank event to occur ? (and meanwhile to block any
compositing). Could we not have a 500ms-and-no-longer approach
whereby if no vblank arrived in that time we would give up on
further waiting as a bad job (?).
execve ("/proc/self/exe", ...);
somewhere in spawning it's child sandboxes (which are setuid root
interestingly). The setuid helper /usr/lib/chromium-browser/chromium-sandbox
seems capable of other funky things: --adjust-oom-score <pid> <value>
eg. that look interesting; presumably it has been audited to death.
Firefox - come back ! all is forgiven ...
The other day the, secret, internal, 'from scratch' re-write of GStreamer integration was announced by StarDivision. You can read the wonderful news on their corporate blog. There is also some amusingly mis-directed marketing effort focused on Ubuntu as well. What does this mean for Linux users ? Nothing. With this great leap forward in Linux support you are unlikely to notice any difference at all; why ? Because all Linux distributions (SUSE, RedHat, Debian, Ubuntu, Mandriva, and more than I can list) have already been shipping GStreamer support since 2006. That was mostly written by Radek Doulik from Novell, with fixes from Redhat's superstar Caolan McNamara.
The real question is: Why would StarDivision want to draw attention to their traditional feature gap, by making noise about shipping multimedia support four+ years late ? while simultaneously alienating valuable contributors and continuing to tear down its developer community (that would love to help close OO.o's feature gap) ? if that interests you - read on:
Winston Churchill said that some people will always do the right thing ... after they have exhausted all the alternatives.. Now of course, for years I've been fondly wearing the GStreamer T-shirt, and promoting it as the future of multimedia. Sadly my 1st minor contributions were a bit late: in 2001, but the love is there; it's a great technology and a badly needed unifying force in the fissiparous area of media stacks. Did I mention I think it rocks ? it is eclectically owned and apparently developed as a traditional open-source project (despite lots of corporate investment).
Anyhow, despite (to my mind) the obvious-ness of GStreamer as the right backend to pick, StarDivision went ahead, chose and implemented the JMF support that they now admit is horribly inadequate; here is how things panned out:
"I have tried all the dev releases of the upcoming OO 2.0 under Linux. Last I have had in use is the 1.9.77 release. In none of these the native insertion of video file in any format that I have tried (raw, avi, xvid, divx, mpg mpeg4) has worked. It simply can't play any of the formats I throw at it."At this point we have Xine and MPlayer mentioned, still the relevance of GStreamer hasn't sunk in.
At this point, the people trying to market against a branch of the same code, with additional features added, start to cast aspersions on its Quality. This is about the only half-way plausible argument they can have without hurting themselves. After all - ooo-build is intrinsically more feature (and fix) full than the original it is based on.
Of course, this argument foundered pretty horribly on missing features like 'Media Playback', given that our GStreamer integration is fairly robust (no known bugs). Is overall product quality really higher with totally inadequate media playback ? Is it really that much better to have nothing than something ?
The other part of the quality argument is similarly self-serving and goes a bit like this: "Their bug fixes are of terribly low quality !", this is usually helpfully co-joined to "This is because they don't have a slow and complicated QA process !". Then, of course there is the FUD - usually trotted out by non-programmer 'community' gurus and swallowed by everyone "The code-base is impossibly complicated, only the original authors could fix it". Of course there is some level of self-stultification, among the arguments: if the original code is of such high quality, how can it be comprehensible only by its original author ? [ hint, code review, and care in coding is perhaps more valuable, long term, than black-box testing ]. Is the underlying code really -that- complex and impossible to hack on ? (usually not). Of course among the smoke of a FUD war, any meaningful metrics of whether these bug fixes are actually bad is never forthcoming; it is just assumed.
Of course, in my view we fix many more bugs than we introduce (there being no shortage of them despite the heavy-duty up-stream, black-box process), and we always have a feature edge, though it changes over time; in large part because we send a lot of our work up-stream ourselves.
Ultimately, since all code has some level of bugginess, it can be hard to discern, for the man on the street, what the best code is. Luckily the Quality argument boils this down to something trivially to understand and remember, irrespective of who wrote it:
"If StarDivision owns it - the code is of high quality, if not the same code is of low quality"
Of course, developing duplicative code, in secret, internally, and
then landing it on the world is not a great strategy for growing a developer
community:
Needless to say, this GStreamer duplication is not the sort of advert that we want out there, that encourages people to contribute. If code is developed in secret, and then dropped from a height on the project - there will be much reduced benefit from peer review, and external contribution all around. Moving in this direction is extremely unhelpful for the future of OpenOffice as an open and inclusive project.
More amusingly, perhaps, there is a cabal of non-developers and business partners who hang around advising StarDivision management on matters of 'strategic' importance, such as this - who of course get advanced notice of these decisions. It is an interesting strategy to empower these people, and not those writing code. It is also curious that, although the revision history of the new GStreamer support is now hidden (with a single code dump), the ten source module file names match our implementation, while differing from the windows, and xine backend pattern; probably just a co-incidence.
I use the name 'StarDivision' above, since it has been made clear publicly that OpenOffice is run at arms length, as a nominally separate business unit. Indeed, Oracle's acquisition of it has only just fully completed. It seems a reasonable (if legacy) name. Perhaps it is a shame that some of the good practice and expertise around Open Source projects that Oracle has in-house is not effectively applied in this piece of the company. People like to give Apple all the credit for their control ambitions around language choice for their app-store, banning their competitors from the arena and so on. That seems rather unfair, Open-Office.org seems more of a crucible of software co-ercion innovation: in order to get your code included it appears StarDivision needs not only to own it, but to do so exclusively.
Clearly, I am a Free Software hacker, not a business man; thus of course, perhaps I've missed something hugely important here around control or somesuch, but since these actions are rationalized to StarDivision's own (humane, and clueful) developers with a pressing 'business' rational, lets look at the pros and cons of duplicating this in-house, vs. the alternative: accepting code ownership, under condition that it is also available under a liberal license:
Of course, I don't think StarDivision's management is actively malicious, they're certainly not stupid - so it is necessary to pad out the re-writing pros a little - there must be a reason: what is it ? Is it really worth fracturing the development effort, wasting resources, re-writing existing, tested, working code, and driving away contributors, simply in order to ensure that StarDivision are the only owner ? is this 'Open'-ness ? How likely is it that external contributors are going to re-write and improve a majority of the OO.o code-base in the next decade anyway (diluting the exclusive ownership) ? Why bother creating conflict and steam-rolling other contributors to this extent, purely in StarDivision's proprietary corporate interest ?
Of course, ideally we would just get the code into OO.o under the LGPLv3 (the outbound project license), it is a tragedy that such a cost is paid, simply in order for StarDivision to have the exclusive right to avoid its terms.
Please note, that this is not a competitive issue. Notice, I am not promoting Novell's version as years ahead of Sun's here. I truly believe that to get the best product for everyone we need a partnership and collaboration of developers inside and outside companies, to create a better OpenOffice for all.
This announcement is non-news, StarDivision re-wrote a small piece of community developed code, and plan to ship it in six months time (in OO.o 3.4). What little news content there is points to an increasingly closed, secretive, and unhelpful development process. Perhaps there are also clear signs of an unwillingness to compromise at all, and a slow dying of the belief that such a thing as an active, and helpful developer community is possible. Please remember that once we all worked together in a more productive and friendly way !
Of course, I anticipate more non-news, if management loses faith or interest in a developer community, and prefers to waste resources rather than working together with others, there are some obvious next steps: waste even more resources ! Unfortunately, as a side effect this yields the development agenda to others, and just builds more walls between those who have common cause to make the code-base better. What a tragedy.
Personally, I believe OO.o can really only thrive and grow if all the contributors work together. By work together I mean a public, transparent co-operation around well defined, fair rules; not a web of tangled back-room agreements. Absent that, I am not optimistic for the future of StarDivision, though it is perhaps positive that they are starting to take Linux integration more seriously - which could be good.
Finally, at some level, this is a sad thing; this is 2.5k lines of code re-written that didn't need to be written (against the current ooo-build patch set size of ~673k LOC). That is a loss of 0.4% of the ooo-build 'edge'. As OO.o, and it's customers finally arrive (in multimedia terms) where ooo-build users were in 2006, I hope they like the scenery: we have long since moved on, as one example: to multi-slide audio.
Update: Amusingly the announcement blog entry finishes: "Don't hesitate to give us feedback." - but strangely, the initial comments and discussion on the article have all been deleted: amazing - what is there to hide ? - the fact that this is duplication ? the bogus quality argument being deployed ?
Update #2: Comments just got re-enabled, showing the great hype on quality. As mentioned, having a fully-pluggable media backend where you can choose Xine or Mplayer or JMF or GStreamer is a terrible idea; hence hard coding GStreamer support. Though of course the calculus of maintaining features as patches imposes some limits to the re-factoring possibilities too.
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)