Stuff Michael Meeks is doing
|
|
This is my (in)activity log. You might like to visit
Collabora
Productivity a subsidiary of Collabora focusing on LibreOffice support and
services for whom I work.
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.
Failing that, there are all manner of interesting things to read on
the LibreOffice Planet news
feed.
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
-
Up early, poked at the poll results - sad to see the same old
Prime Minister in office; a change is as good as a rest (so they say).
-
Prodded mail, Joey making some great progress on bootcharting
some of our slower systems. Wrote LXF column on Moblin.
-
Amused by the talk
(video)
of re-writing OO.o based on JavaFX. Of course - there is much
about the OO.o code-base that betrays it's palaeolithic origins as a demo
application for a trendy new toolkit (now VCL) from 20+ years ago - many of
which badly need to be undone with a clean re-design. Of course - opinions
differ on how long it would take to re-write OO.o in C++ - ohloh
suggests it is > 2000 man years. Lets briefly drink the cool-aid and believe
that modern managed languages magically solve all complexity problems, are the silver
bullet, give a 10x programmer productivity boost, and that we can throw out
a chunk of the component, toolkit code. That leaves perhaps 200 man years of
work. With Sun's OO.o team of under 50 programmers, assuming they abandon
OO.o development completely, that is a four year endeavour; but if we look on
the pessimistic side, it could be several decades. Who knows - it may even
happen; Corel Office's total melt-down from porting to Java occured (after all)
when CPUs were slower, RAM was more expensive, garbage collectors were worse, and
Java was far less mature & well understood. At the end of the day though,
where is the win for 200 man years ? a newer code-base, with newer, different
bugs; a different set of performance problems; perhaps some better architectural
under-pinnings; the deployment problem is moved from one of deploying and
managing the right version of a fat-client OO.o to the right version of
fat-client JavaFX (and version management, and certification of multiple
applications, each against a thick-client stack in the same browser is
very much an un-solved problem AFAICS). Of course any idea that this much
Java is going to run on your phone, or that somehow (magically) the UI will
'just work' on small devices without substantial extra work is a pipe-dream.
Personally - luddite that I am, I'd prefer to stick with re-factoring and
optimising the code in C++, and adding incremental managed code
(if any) for new UI features.
-
Poked at Intel 2D / cairo rendering performance again. Interestingly
my cairo trace seems to run faster on the Intel / 2D netbook than my laptop;
interesting, perhaps the problems lie elsewhere.
-
It is interesting to see Sun promoting the MySQL
extensions for OO.o, it looks useful enough, but is interesting primarily for legal
reasons; libmysql - last I looked, instead of being LGPLv2 (or v3) was
GPLv2 (ie. incompatible with LGPLv3) with an EXCEPTIONS-CLIENT
list - that (interestingly for 5.1) does not include the [L]GPLv3 - in it's
FLOSS License List, although the web page does (and
has a different text). This curious approach to licensing, combined with the
obvious gotchas for ISVs (sic) was the sometime basis for MySQL's 'interesting'
revenue model - for which they would arrive and demand retrospective compensation.
The curious terms also (seem) to mean (to me, IANAL) that anyone unwittingly bundling
the mysql connector with OO.o on a CD, will need to include complete source for
OO.o; and can they compile ICU in ?
( at least one other license that's not listed there - or is ICU BSD ). Oh, and of
course combining that extension with any other non-open-source extension seems
unfortunate too. It is also curious that the component's page
lists the license as LGPLv3 - does this herald a new dawn in client
licensing sanity from MySQL ?
-
Looking deeper; downloading the Linux extension (essentially a .zip file) as
you can do here
(please do) contains a full copy of the LGPLv3, with this as the only license flagged,
and inside the .oxt
libmysql.so.16 - it would be great to get the source
for that library under LGPLv3 too (or was that already announced elsewhere ?). Of
course if this was a simple licensing blunder, would it be right to hold Sun to
it ? odd -
but potentially very positive if Sun is going the LGPLv3 route here.
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)
