consh / News: Recent posts

Today, I finished 0.01b. It's very much like 0.01a, but a LOT more usable. I re-did the run-time environment directory structure to allow multiple conshd instances to be running on the same machine, I improved conshtool to the point where you can (and should) use it to start and stop conshd, and *drumroll* we have environment variables!

Consh started out as a final project for a class in parallel and distributed computing I just finished. I'm continuing to work on it as a utility for shell junkies like myself who have multi-core CPUs (who doesn't these days?) and want an easy way to actually *use* them with as little tediousness as possible. Consh is one such solution--it provides a network overlay that abstracts the CPUs of hosts on a trusted LAN into a collection of uniquely-identifiable command executors (a.k.a. "workers") to which consh commands may assign work, with which consh commands may synchronize, and from which consh commands may receive shell command output from said work. In short, it creates a virtual multicomputer out of one or more computers, and lets the user tell the virtual CPUs (the workers) to run commands for them and give them back the output. So far, consh provides a way to run a given list of commands on one or more workers (the "co" command), a way to distribute iterations of a "for" loop across one or more workers (the "cofor" command), and a way to synchronize with one or more workers via a distributed barrier (the "cosync" command). In the near future, consh will also provide a distributed environment variable collection and a way for workers to send and receive data from one another (through environment variables). To allow for otherwise normal shell behavior, consh runs on top of a Bourne-compatible shell and simply delegates typical shell commands to it.... read more