Updating the TCPDF library in Joomla! 1.5
TCPDF is an excellent PHP class for creating PDFs from dynamic (or static, for that matter) web content. Unfortunately, the version of TCPDF bundled with Joomla! 1.5 (all 1.5 releases after at least 1.5.8 - someone please correct me if I am wrong - was version 2.6.000_PHP4, dated March 7, 2008. It's also not very PHP 5.3-friendly (there are other parts of Joomla! 1.5 which are not fully compatible with PHP 5.3, but this article will focus on TCPDF). Time to freshen up, methinks.
Broken Windows updates for .NET
Ah, into the land of (broken) Windows we go...
I despise Windows. Have I said that before? Here, in case I haven't, I'll say it again. I despise Windows. That feels better. It's good to get such things off one's chest. What a hopelessly broken operating paradigm. Oh, well. It's gotten better, I guess. that is to say, it used to be even worse.
I've been spending much time of late working between zypper and yum on various flavors of Linux and now, eComStation, which has its own port of yum. Of the two, I prefer zypper, though either is head and shoulders beyond the inane Windows patching system. However, when in Rome...
CRTs vs LCDs in 2011/2012
An interesting thread cropped up on the eComStation Technical mailing list on Yahoo! in the past few days. One of our list members was inquiring about the ability to set refresh rates in the Panorama video driver. Short answer: you can't (well, at least, not yet). This is covered in the VESA FAQ. Apparently, the original poster has a CRT which requires proper tuning of the driver for his monitor's refresh rate. One of the first responses to come back to him (aside from the correct answer, pointing him to the FAQ) was the obvious question: "Why are you still using a CRT?"
I suppose what has amused me the most about this little exchange was the assumption that by now, CRTs have become yester-tech, and that *all* truly modern systems (this was a fresh install of eComStation 2.1) should be outfitted with LCD monitors.
I was going to jump into the post, but instead, I'll just migrate some excerpts here, and include my own commentary at the end.
Ramdom thoughts on the 2011 (and beyond?) Firefox release schedule
As I sit here at Panera Bread, catching up on some tech news, an article caught my eye concerning Mozilla's new approach to updates and, tangentially, the (revised) 2011 Firefox release schedule. This started my own wheels turning, as this has been a bit of an annoyance for me, so I thought I'd just jot down a few ideas...
Concerning Firefox's 2011 release schedule:
Why?
We (I say "we" because I do/have contribute(d) from time to time) have some bugs in Bugzilla which date back several years (some to the Netscape Communicator days, inherited by the Mozilla project - no kidding!). These have yet to be quashed, and all the while new "releases" just keep coming down the pike, bringing with them their own share of new insectoids. Wouldn't it make more sense to stay at a reasonable "release" level, and just fix it before adding new features (and after all, isn't the purpose of a new "release" to introduce new features)? We already have a mechanism in place for extending the functionality of the browser through plugins and extensions, anyway, so what's the point? (If Mozilla wants to emulate Redmond, then they should consider that under the hood, Windows 7 is NT 6.1, anyway, and Microsoft got a head start with NT growing out of OS/2 - NT started at version 3.)
Updating Firefox on Linux: the Dreaded “Couldn’t load XPCOM”
I bumped into this annoyance while updating my openSUSE 11.4 workstation tonight.
There are numerous mentions of this issue on the net, and numerous suggestions for addressing it. However, none of them (which I saw) really hits on the underlying problem, which is that somewhere, somehow, XPCOM can't start.
To understand what's going on, it's important to have a basic understanding of what XPCOM is, and how it is involved with Mozilla apps. XPCOM is an acronym for "Cross Platform Component Object Model," which is Mozilla's equivalent technology to CORBA or Microsoft's COM. Like any other "object model," XPCOM's function is to provide a modular framework vs a monolithic one. This modularization allows XPCOM to be (mostly) platform-neutral, making it possible to run the Gecko rendering engine on a variety of platforms. So, as the Gecko engine is composed of XPCOM components, if XPCOM cannot start, Gecko cannot start. If Gecko cannot start, then there is no rendering engine for the application, essentially stopping whichever Mozilla-based app one might wish to run, before it even gets started.
Rsync error 5 may be exactly what it says
I use (and love) rsync on a variety of platforms. On Windows, about the easiest implementation I've found is DeltaCopy.
Recently, though, I've been seeing a problem at a particular client running DeltaCopy, and only for one machine (which happens to be the box running the server component, as well. Wanting to rule out the obvious, I suggested he run a full chkdsk pass against his local drive. After that, we got a slightly different error message:
@ERROR: chdir failed
rsync error: error starting client-server protocol (code 5) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/main.c(1504) [sender=3.0.4]
Error starting client-server protocolRsync.exe returned an error. Will try again. This is retry number 1 of 5
Well...
Various sources on the net point to bad passwords, tabs in command lines, and such. In fact, I originally suspected a bad password...until I went looking.
All of the jobs for this machine back up to an eSATA-connected RAID volume. I have one directory for each day of the week located under the root of the volume. Well, upon browsing the volume's contents, I found that all of my backup directories (virtual directories, in DeltaCopy-speak) were gone! So, apparently, chdir did indeed fail, as there was no target directory available.
I re-created all of the daily directories, set it off manually, and it is happily backing up as I write this.
Go figure.