Compared with the standard tools
What Xi-Batch, Xi-Exec and Xi-Text add to cron, ssh and lp, stage by stage through an automated workload.
Most organisations run scheduled, unattended work. Some of it is the overnight cycle; some of it runs hourly, on a file arriving, or at the end of a shift. The shape is the same. Work is scheduled, it executes across a number of servers, and it produces output that has to reach a printer, a file or a person. It is the least glamorous part of the estate and the part that must not fail.
Every operating system ships something for each stage, and for a single machine running a handful of jobs they are the right answer. Production estates ask for more: dependencies that span hosts, output that has to arrive, and work that reaches other machines without handing out shell accounts.
Each page below takes one stage, says plainly where the standard tool is sufficient, and sets out what Xi adds when it stops being.
The three comparisons
| Stage | What ships with the system | Where it stops | What Xi adds |
|---|---|---|---|
| Scheduling | cron |
No job-to-job dependencies, no coordination across hosts, no display, no intervention once a job has started | Xi-Batch |
| Remote execution | ssh and a shared key |
Shell access on every target, key distribution and rotation, no per-operation control, incomplete audit | Xi-Exec |
| Output | lp and CUPS |
No routing by form type, no restart at the point of failure, no per-user or per-group control of printers | Xi-Text |
Each row is a page. Each page says where the standard tool is the right answer before it says anything else.
Scheduling
cron starts things at times. It cannot express that one job depends on another,
cannot coordinate across hosts, shows nothing about what is running, and hands
back control the moment a job starts.
Remote execution
Scheduled work has to reach other machines. The usual arrangements - a shared key, a service account with a shell, an SSH command that became an interface - all amount to granting the ability to run arbitrary commands somewhere else.
Output
lp and CUPS are fine for a desktop. They cannot restart a failed
sixty-thousand page run at the point of failure, route by the form loaded rather
than the printer named, or stop most of the organisation reaching the cheque
printer.
Why one supplier for all three
These are not three unrelated problems. They are three stages of the same operational cycle, they fail together, and they are usually run by the same team.
The scheduling vendors do not sell print management. The print vendors do not sell schedulers. Almost nobody sells the execution layer as a product at all.
We build all three, and they are designed to work together.