Drizzle translations progress
First of all, that’s to everyone who’s pitched in so far. There are more messages to translate coming… So far we have contributions in 15 different languages. Quite impressive. Check it out:
A slight engineering puzzle is coming up. As you can see from the german output, “Unknown database ‘lskfs’” wasn’t translated. This is because that error message is actually stiched together on the server and sent back over the wire, so it’s not executing in the context of the locale the client is connecting as. That’s fine for messages without parameters, but for ones with parameters, which would be the main reason to build on server and send over the wire, running gettext() on the client gets us no where. Not sure what the right answer to this is yet…
Drizzle i18n
Anybody out there know more that one language?
We’ve got gettext going in the drizzle source now, and although we don’t have all the strings marked yet, we do have a start, and it’s time to get going on translating!
If you’d like to help out, just head over to launchpad, pick a language and get going! You may want to go to your launchpad settings and pick your preferred languages first, though, else the list of offered languages might be a little odd.
I’m guessing the easiest ones will be “English (Australia), English (Canada) and English (United Kingdom)” … but I could be wrong…
Online Logging FTW
I was just reading Sheeri’s post Why You Want to Switch to MySQL 5.1, and my favorite 5.1 feature jumped out at me.
Online, table-based logging.
It doesn’t get a lot of press, which is sad, because it’s hella useful. I can’t tell you how many times I’ve showed up to a client’s site to help with performance tuning, started with “well, let’s look at the slow log” and (as I’m sure we all know) been foiled by the fact that they don’t have it on and can’t do a server restart. I was even at a client a couple of weeks ago where they were actually using the CSV engine support of this… although I’d never really found that all that interesting myself.
Online logging. It’ll make all the ($gender_of_sexual_preference) love you!
RIP: errmsg.sys
Brian is merging in a patch I’ve been working on that kills errmsg.txt, errmsg.sys and comp_err. In its place is (currently) a header file with a static list of error messages and codes. To handle the i18n of the messages, we’re starting to use gettext. Not only is this a standard thing, but it makes it much easier for us to translate all of the rest of the strings we output inside of Drizzle. (turns out, there are quite a few of them)
Soon I hope to be uploading a .pot file to launchpad so that the i18n work can get underway.
Next on the list as far as this goes, re-working how all of the error message lists are managed internally, and doing some thinking on why we have our own charset stuff that isn’t the system iconv() based stuff.
Things I like about OpenSolaris
Yesterday I spent some time trying to figure out how I can better support people who are running OSX. I came to the conclusion that it’s not possible for me to do this, and in fact, Apple doesn’t want me to. As part of that process, it made me rethink OpenSolaris a little bit. Here’s my list of things I like about OpenSolaris:
- It’s not OSX
- I can install it in a VM
- It’s trying to get packaging right
- It’s Free Software
Caveats to the above list:
- My reservations about a brand new ZFS-based packaging system
- It may be Free Software, but it’s CDDL
Thank you Sun, for not being the cess-pool of arrogant wanks that Apple is!
OpenSolaris EPIC FAIL
I decided I’d be a good sport and try to do some build work for Drizzle on OpenSolaris to make sure we weren’t accidentally Linux-ifying something. Nevermind OpenSolaris installing an nsswitch file set up to not use DNS by default. Nevermind OpenSolaris reinventing the wheel for package management rather than starting with a package management system already in use by people (or and then fixing the things . Nevermind the GPL incompatible CDDL license… I’d be a good sport and give it (another) try.
I should add, in all honesty, I really do want OpenSolaris to be good. I think monocultures are bad, and I think Solaris can be useful in the growth of the ecosystem.
Step one. Install bzr.
pkg search bzr
Nothing. Wasn’t expecting much. That’s ok. Grab tarball. Unpack.
FAIL
Silly me. There is no sudo, so I had become root first (sure – I’m sure there is a better solaris way to accomplish sudo… please provide a sudo command line that accesses the superior solaris tool please?)
tar xvfz bzr.tar.gz
tar: z: unknown function modifier
Must use gtar. Old broken Solaris tar is still default for root user. Pointless. Stupid. Must die.
Ok. Fine. Unpack bzr.
python setup.py build
FAIL
many error messages about ld not working. Something like this:
ld.so.1: ld: fatal: libld.so.4: version `SUNWprivate_4.2′ not found (required by file /usr/bin/ld)
Fine. ld is installed but for some reason doesn’t work.
pkg install SUNWprivate_4.2
FAIL
That’s not a package… After cursing and googling, I finally found this:
pkg install SUNWtoo
THAT certainly makes sense from the error message.
Somewhere in looking for the answer above, I also did:
pkg install gcc-dev
(Notice lovely lack of SUNW prefix) This seems to have installed all of the gcc/automake/autoconf I need. First nice thing… although gcc-dev makes me think it’s going to be files to help me hack on gcc… but I’ll live with it. It’s DEFINITELY the best part of the pkg system so far.
Yay. bzr is installed.
Grab my drizzle tree:
bzr init-repo drizzle cd drizzle bzr branch lp:~mordred/drizzle/codestyle
Woot! That works!
cd codestyle ./config/autorun.sh
Woot! That works! Up to date autoconf and automake even! (beating CentOS/RHHEL 5 here… really? autoconf 2.59 and automake 1.9? come on RedHat…)
./configure
Can’t find libevent… that’s ok. It’s a new system.
pkg search libevent
FAIL
silly me. It’s SUNWlibevent. How obvious. (Hint to Sun… the legacy Solaris users are not the target audience you should care about if you want new users here… There are many places where Linux has been eating your lunch for years. Package naming is apparently one of them. Fix it. Change. Grow up. Welcome to 2008 )
pkg install SUNWlibevent ./configure
Can’t find readline. Sigh. That’s less ok. It’s a standard lib guys… oh, wait… hrm. CDDL? Anybody remember why it annoys me?
FAIL FAIL FAIL
There is no readline pacakge.
That’s ok. I’ve been doing this for a while… I know where ftp.gnu.org is. (You know, RMS is right … it IS GNU/Linux that we all run…, with a heavy emphasis on the GNU part.)
Grab readline tarball.
Unpack.
Build.
Install.
Back to drizzle…
./configure
FAIL FAIL FAIL
no ncurses. no ncurses package either.
download. unpack. build. install… (why is there a package manager on this system? )
Back to drizzle.
./configure
no pcre. I can live with that… It’s in SUNWpcre
./configure
FAIL
can’t find pcre.
#$%@%^@
Whoops. Even though OpenSolaris decides to install pcre headers in /usr/include/pcre, which it includes a pkg-config .pc file specifying, pcre doesn’t depend on pkg-config. This is good because…
FAIL FAIL FAIL FAIL FAIL
there is no pkg-config package.
Swear. Curse. Spit. /me punches OpenSolaris in the face.
I KNOW it has to be in there, OpenSolaris is running Gnome after all.
google. read forums. WHERE IS pkg-config??!??1
SUNWgnome-common-devel
Silly me.
pkg install SUNWgnome-common-devel ./configure # finally works. make
EPIC FAIL
The final straw for the night… OpenSolaris 2008.05… the most recent release… released this year… 2008… ships with gcc 3.4. From 2004. That gcc 3.4. There is also no gcc4 package. It’s not even old gcc4.0… it’s gcc3.4.
Sigh.
It’s 1AM. I’ve picked on OpenSolaris enough for one night. I’ll give it another go tomorrow.
