mysql -BNe 'SELECT COUNT(*) FROM TABLES' information_schema
While browsing my servers Munin reports, I recently noticed how used disk space was constantly increasing on a filesystem which should not have been seeing such growth. After a bit of digging, it appeared the
/usr/local/var/varnish/(host) directory was filled with dozens of sparse files all named
varnish.??????. What could have been happening ?
Unless you've been living under a rock these last few weeks, you are aware of the fork of OpenOffice.org created by The Document Foundation (TDF), called LibreOffice (LO), and wondering whether some code was already usable.
Well, I happened to have a mostly unencumbered Saturday, so I took it to try my hand at building the latest LO dev build from TDF...
The second Open Source Developers Conference (OSDC) will be held on saturday 9th and sunday 10th, October 2010 at "Carrefour Numérique de la Cité des Sciences", in Paris. OSDC is a cross-language event, set up by multiple french language-specific non-profits:
- PERL: Mongueurs de Perl
- Python: AFPy (Association Francophone Python)
- Ruby: Ruby France
- SmallTalk: European Smalltalk User Group
Much like many Drupal devs, I happen to make fairly intensive use of Dropbox, and even use a "pro50" account to sync my always increasing set of "current" source folders, including checkouts of all major Drupal versions and lots of contrib.
Which means that, beyond the number of gigabytes of data Dropbox has to sync, the number of the files making up these gigabytes has also been increasing, currently to around 100k files. After I started playing with checkouts of the Drupy project in preparation for the Drupyx experiment, I noticed that, when I created some new files under the Drupy directories, their creations and subsequent changes would not be tracked by Dropbox, but they would correctly sync if I renamed the Drupy directory itself or a directory above it. Something like this:
|Action||Result on Dropbox.com|
|mv ~/Dropbox/src/drupy/src/foo.py ~/Dropbox/src/drupy/src/bar.py||Ignored|
|mv ~/Dropbox/src/drupy ~/Dropbox/src/drupa||Full sync below ~/Dropbox/src/drupa|
|mv ~/Dropbox/src/drupa ~/Dropbox/src/drupy||Full sync below ~/Dropbox/src/drupy, including "foo.py"|
And all this while operations on a PC running Windows tied to the same account did not experience any similar problem. What could be going wrong ?
If you like Opera Dragonfly, as I do, you may have stumbled upon a small annoyance: if Opera is configured to start with the previous window, if you use Dragonfly in a separate window - maybe because you use a dual screen config - if you happen to close the main Opera window with Dragonfly still open, and close Dragonfly afterwards, then you will notice that Opera complies with your choices: when you restart it, it restarts with the main browsing window closed and Dragonfly opened.
At this stage, closing Dragonfly won't help, because Opera will faithfully restore it at every launch. Annoying. Luckily, there is a very simple workaround if you find yourself in that situation...
Like any VCS, CVS is able to show the status of the current directory when compared with the repository from which it is checked out.
However, unlike SVN, GIT, or bzr, which by default show only a rather compact set of information, CVS provides already verbose information, with only an option to add even more, and no terse mode.
Luckily, piping its output through a few commands allows one to obtain such a compact
cvs status display. I tend to use this, aliased to
alias cvsst="cvs st | grep -vE 'revision|Sticky|^$|==|Commit' | sed -r 's/^File: |Status: //g'"
Spending most of my web time in Opera, I had noticed that on one of my PCs, hovering over a hypertext link (i.e.
<a href="..." ...>) had ceased displaying the target of the link in the UI, and there didn't seem to be a setting to make it appear again. Even when upgrading, that annoying behaviour kept stuck.
As one can expect, it turned out to be simple to fix, just not obvious in the Opera UI. Here is the procedure:
The problem : Drupal awfully slow on Vista (and Seven) with Wampserver
For some time now, I'd been severiously annoyed by the (utter lack of) performance of Drupal 6 and 7 on my home PC, which happens to be running Microsoft Vista: considering I was used to getting page times around 200ms on a fractional Celeron with Apache 2.2 on a Linux server hosted comparatively far across the net from that same machine, I felt the 5 to 15 seconds response time per page on this local machine with a quad core and 3 GB RAM were really making me lose my time.
After some time spend googling around, I stumbled upon an incredibly simple tip, which made the 5 to 15 seconds per page drop down to around 1 second when logged in, and well below 500 ms when not logged in. It's incredible what ONE single character in a plain text file gets you under Vista :-)
UPDATE 2010-01-23: David Hogg tells us (see below) that this works for Windows Seven too
So at long last, GW8 is becoming reality :
As a long time developer on GroupWise (hey, I did this even before I started on Drupal !), I'm glad to see the product evolve. And already a planned upgrade for a customer :-)
Now, if I could find a project merging both... to this day, I've only used Delphi, both with OLE and SOAP, to communicate with GW.