summaryrefslogtreecommitdiff
path: root/system/ts/README
diff options
context:
space:
mode:
authorRichard Ellis <rellis@dp100.com>2010-05-12 23:33:50 +0200
committerDavid Somero <xgizzmo@slackbuilds.org>2010-05-12 23:33:50 +0200
commit15447044a34ee059b64c00e6734fcbb708751258 (patch)
tree67fc31b20666740ac6547646b95d2cef22988783 /system/ts/README
parentea536a01a45d688e9a62e4dbfd4ae3079f40d790 (diff)
downloadslackbuilds-15447044a34ee059b64c00e6734fcbb708751258.tar.gz
system/ts: Added to 12.2 repository
Diffstat (limited to 'system/ts/README')
-rw-r--r--system/ts/README37
1 files changed, 37 insertions, 0 deletions
diff --git a/system/ts/README b/system/ts/README
new file mode 100644
index 0000000000..319af498e1
--- /dev/null
+++ b/system/ts/README
@@ -0,0 +1,37 @@
+Task spooler is a Unix batch system where the tasks spooled run one after
+the other. The amount of jobs to run at once can be set at any time. Each
+user in each system has his own job queue. The tasks are run in the correct
+context (that of enqueue) from any shell/process, and its output/results can
+be easily watched. It is very useful when you know that your commands depend
+on a lot of RAM, a lot of disk use, give a lot of output, or for whatever
+reason it's better not to run them all at the same time, while you want to
+keep your resources busy for maximum benfit. Its interface allows using it
+easily in scripts.
+
+Features
+
+Task Spooler allows one to:
+
+ * Queue jobs from different terminals.
+ * Use it locally in the machine (not as in network queues).
+ * Have a good way of seeing the output of the processes (tail,
+ errorlevels, ...).
+ * Easy use: almost no configuration.
+ * Easy to use in scripts.
+
+At the end, after some time using and developing ts, it can do something
+more:
+
+ * It works in GNU systems with the GNU c compiler (Linux, Darwin,
+ Cygwin, FreeBSD, etc).
+ * No configuration at all for a simple queue.
+ * Good integration with renice, kill, etc. (through `ts -p` and process
+ groups).
+ * Have any amount of queues identified by name, writting a simple
+ wrapper script for each (I use ts2, tsio, tsprint, etc).
+ * Control how many jobs may run at once in any queue (taking profit of
+ multicores).
+ * It never removes the result files, so they can be reached even after
+ we've lost the ts task list.
+ * Transparent if used as a subprogram with -nf.
+