cron timing shortcuts

Posted on by D Ruth Bavousett

I had occasion to discover this recently–I’ve used cron for years, but never knew this!

You can shortcut some of the times you might commonly use in your crontab in Debian (and, most-likely, in other distros).  For instance:

  • @yearly
  • @annually
  • @monthly
  • @weekly
  • @daily
  • @midnight
  • @hourly

All of these is equivalent to a “standard” time:  @hourly, for instance, is the same as saying “0 * * * *”, et cetera.

That’s cool as heck, of course, but the one that really wowed me was this one:  @reboot.  This will let a non-privileged account run something at startup, WITHOUT it having to be in /etc/init.d!  Use it like so:

@reboot <your script reference here>

Nice trick, that!

Parser snippets

Posted on by Joe Atzberger

On the oft-informative IRC channel #code4lib, jrochkind mentioned working with a new ruby parser framework parslet.  It runs based on a parsing expression grammar (PEG), essentially a notation for language specification.  You can think of it as the kinder, gentler Extended Backus-Naur Form.  Not as complete, but possibly more useful.

Then the newly core perl6 rules were mentioned as another widely available basis for constructing parsers.  It seems commonly used of languages have come a long way towards the functionality once available mainly from dedicated tools like ANTLR.

Armed with tools like these and adequately specified, er… specifications, it is possible to imagine standards bodies would be able to produce new reference implementations for versions of important specs like EDIFACT, SIP2 (or SIP3)… even MARC21.  That is, we could have additional framework/validator available for these otherwise arcane formats that was authoritative.  And not one that runs on top of a FoxPro database in Windows NT.  Oh, sweet sweet reference implementation…

If you’re interested in how these tools might be used in libraries soon, hop on channel and ask about new parsing in Blacklight.

Defaulting to functional but slow

Posted on by Galen Charlton

Nothing beats the convenience of doing apt-get install mysql-server or apt-get install postgresql to get an instantly working open source DBMS. MySQL and Postgres are part of the foundations of a lot of open source library software, including ILSs (Koha and Evergreen), discovery interfaces (VuFind), digital repositories (DSpace and Fedora), and content management systems (Drupal, MediaWiki, Moodle, WordPress).

But there’s a catch: the packaged version of an RDBMS is usually optimized for working out of the box. But since the packager can’t control how big the box is, as it were, that means that the database tuning settings set by the package are usually for a small system. The upside to that is that you can dust off a five-year-old laptop, install your favorite flavor of Linux on it, and get up and running quickly with an RDBMS-based app.

The downside is that if you do the same thing on a production database server, using the default settings can mean that even a small database can perform slowly, and sometimes quite slowly indeed. In particular, the key to performance with most RDBMSs is using as much RAM as possible and touching disk as little as possible. Particularly in the case of MySQL, the default settings can leave gigabytes of system memory unused. You’ve paid for your memory, make it sing for its electrons.

Tip: after installing a DBMS, tune it (although you may need to load your production data first to get the best results from the tuner). In the general case, that can be a very involved process, but the starting point can be quite simple. If you’re using MySQL, run mysqltuner. If you’re using Postgres, run pgtune.

Want the tao of database tuning in dead tree form? I’ve read and recommend both High Performance MySQL by Jeremy D. Zawodny and PostgreSQL 9.0 High Performance by Gregory Smith.