rlucas.net: The Next Generation » Uncategorized

The “user” virtual file / workspace in Prolog.

rlucas — Thu, 11 Feb 2010 19:35:00 +0000

When you’re first learning about Prolog, sometimes you’ll read books or tutorials that show you typing in “clauses,” and then immediately thereafter typing a “query.” If you use a visual or browser-based Prolog implementation, you’ll discover that there are two “modes” (my term), one for the input of the program / database, and one for querying. The query form is denoted by the prompt “?-” as in:
?- my_query_(Variable).

To me, it was somewhat confusing as to why and how I had to keep separate my program from my queries, since I was used to REPL-type interactive programming (e.g. irb for Ruby).

Later, in reading the SWI-Prolog manual, I saw reference to this odd snippet in the “Adding Arithmetic Functions” section:

?- [user].

:- other_stuff(x).
…

It appeared that [user] was changing the mode from query-mode to program-mode, and allowing me to define new predicates.

Well, close. It turns out the way to think about this (can’t seem to find it in the SWI-Prolog manual) is that the square-bracket notation is the “load file” shortcut, and Prolog comes with a virtual file known as “user.” When you query:

?- [user].

and then go on to get:

|:

as your new prompt, you’re loading the “user” file which is like opening a handle on STDIN. (Not precisely, but close enough.) You can then type your program entries, /but you must terminate them with EOF/ (ctrl-D).

This bit of prerequisite knowledge would have saved me a lot of puzzlement and trial-and-error. A shame that Prolog, despite a nearly 40-year history of continuous use and usefulness, has such a high propaedeutic load.

“Getting It” in IT Security

rlucas — Fri, 16 Oct 2009 21:39:11 +0000

Look, folks, PKI is hard to grok fully. But if your entire business is being a trust provider (SSL cert vendor), you should try.

GeoTrust makes their Root Certs (the things you download and install in order to tell your computer, “trust things from this authority”) available via an insecure connection:

http://www.geotrust.com/resources/root-certificates/

Unreal.

Some Gotchas with using svndumpfilter

rlucas — Thu, 13 Aug 2009 22:41:09 +0000

A few things:

1. svndumpfilter can take multiple args, e.g.

$ svndumpfilter include /x /y /z > mydump

to include /x, and /y, and /z. It can’t, however, do both include and exclude at once. In theory, you can run multiple dumps when you later load them, so you could (sort of; see below) accomplish the sameish thing with

$ svndumpfilter include /x > mydumpx
$ svndumpfilter include /y > mydumpy
$ svndumpfilter include /z > mydumpz

2. HOWEVER, if you have ever MOVED a file within the repository between (in the example above), /x and /y, you can’t rely upon doing it piecewise. That’s because the references within the loading process during the load of /y will no longer be valid as they point to /x/whatever.

3. It is commonly suggested that one edit “Node-path:” entries within the dump in order to fix up directory structure issues. NOTE that you MUST also change “Node-copyfrom-path:” in the same manner. Trickily, Node-copyfrom-path is only present in nodes that were (surprise!) copied from another node. This is of course tied to 2. above.

—

What is all this about, you ask? Well, it turns out that if you have a single respository with a lot of sprawling projects all under /trunk, you might need to break them out. (For example, if you intend to upload your repository dump to someone like a CVSDude or Beanstalk).

The error message that got me was something like:

svnadmin: File not found: revision 91, path ‘/trunk/x/whatever’

Technologies I want an excuse to use…

rlucas — Thu, 04 Jun 2009 00:15:52 +0000

Cassandra, the Facebook-derived, neither-row-nor-column-oriented-quite, massively distributed data store.
New hybrid languages that run atop Java VMs: Scala and Groovy.
Hadoop. Just ‘cuz.
The R statistical computing system.

Password Policies Must Be Disclosed!

rlucas — Thu, 20 Jul 2006 07:00:00 +0000

Most all web applications require some sort of username and password to login. However, you never know upon signing up how the application (site, service, whatever) will treat your password. – Option 1: The app does what all good applications, having been entrusted with your password, ought to do: it passes it through a one-way hash function (ideally with a random salt), and stores /only/ that hash code. There is *no* mathematically feasible way to retrieve your password, given only the hash code (although in some cases dictionary attacks work). Hence, if you forget your password, they have to send you a new one, but at no time does a second human have a chance to see your chosen password. – Option 2: The app is brain-dead, and stores your password in plain-text, (or in a symmetrically encrypted form where the decryption key is programmatically available to the app). These boneheads become recognizable when, upon using the “forgot password” functionality, they /send back your original chosen password in unencrypted email!/ (Dear reader, it should hardly be necessary to describe why this is a problem, but consider that in our wireless age, every unencrypted communication may as well be considered public knowledge.) There are exceptions, of course, where option 2 is quite reasonable; the venerable mailing list manager Majordomo tells you up front, “/Do not use a valuable password as it will occasionally be emailed back to you in cleartext/,” which tells you right up front what the situation is. Yet, any number of ostensibly professionally-run web apps — /many of whom anticipate being the lucky recipient of my credit card number to consummate a transaction/ — cannot be bothered either to properly protect my password or to inform me about their practices. *Therefore, I propose:* a “Password Statement”, as an adjust to or embedded within a site’s privacy and security policies, that describes how they plan on treating your shared secret (password). This statement should be summarized in a one-sentence line next to the password box on the registration dialog, with a link to more information (much as has become the /de facto/ standard for a statement about spam policies). Finally, I propose a voluntary “seal” program whereby a TRUSTe- or Verisign secure site-like seal is made available, subject to a benign entity’s copyright and trademark protection, to both signify a site’s password policy at a glance and to serve as a link to the password statement.