Problems We Solve

You shouldn't have to understand an entire operating-system project to decide whether one part of it helps you. Start with the work you're trying to do: find a file, reuse a library, keep a job running, share a workspace, recover a service or test a machine-level change.

Rubian addresses interactive work and programming. Kestowv adds a systems foundation and a pilot environment for service operations and workload evaluation. The guides below explain the interfaces in supplied environments. Optional commands and host requirements depend on your build; the availability guide lists those differences.

Finding the work shouldn't be the work#

A bare prompt doesn't tell you which files matter, where yesterday's work went or which commands are available. Repeatedly walking directory trees and guessing command names costs time before the actual task begins.

Rubian starts with an inventory of the environment, commands and accessible home files. Categorized views give you places to begin, while returned paths can become input to the next operation. Command discovery also shows what the supplied environment actually exposes. When that view becomes stale, scoped refresh controls let you update commands or request a deeper file scan.

For example, find the files for a report, retain their paths and search their contents without starting the search from scratch at each step. Categories describe locations, not an AI understanding of every document, and scans remain limited by access.

Read Startup, discovery and recall, Files and paths and Search and process text.

A useful command should be reusable code#

Terminal output is often formatted for a person, then parsed back into data by another script. Changes to spacing or presentation can break the handoff.

Rubian commands use Ruby arguments and return values. Where an operation returns structured data, the next expression can use that result directly. A search can return matches for filtering and reporting; an interactive expression can grow into a named method or a saved project procedure. You don't need an AI model to do this.

That doesn't make every host command a structured-data interface. The manuals distinguish returned values from printed output so you know what your program can rely on.

Read Command language and results and Search and process text.

Use the software you already have#

An installed library isn't much use if every small task requires writing a new wrapper around it. Moving to a new environment also shouldn't mean abandoning useful host tools.

Forge exposes compatible Ruby library functions, classes and value extensions inside Rubian. Discovery and registration reports help you see what's callable and where compatibility fails. Host-command support lets you continue using installed utilities alongside Rubian procedures.

You can bring a compatible library operation into an inspection or processing task, then save the procedure when it becomes routine. Compatibility is selective: a discovered library name isn't a promise that every interface works.

Read Libraries with Forge and Shell tools and customization.

Finish ordinary file work in the same environment#

An inspection often turns into a small edit, a log search or a package to hand to someone else. Rubian includes file and text operations, a line editor, quick writing commands and access to host archive tools, so those steps can remain part of the working procedure.

Search a log, retain the matching records, write a note and package the relevant files. Host files and Rubian-managed files have different operations; the guides identify which resource a command changes.

Read Editing and archives, Files and paths and Search and process text.

Keep the work when the session ends#

Command history can show what you typed without explaining what you meant to do next. Files, code and notes can survive a session but still be difficult to reconnect.

Rubian provides persistent managed files and, in configured environments, named projects and session notes. A project groups working files and source; a timestamped note records the next action. Managed-file persistence uses its own storage and recovery mechanisms, separate from ordinary host-file operations.

Leave an inventory review with its unresolved machines recorded, then return to the same project's files and instructions. Persistent files and notes don't mean an arbitrary running process survives a restart.

Read Projects and session notes and Files and paths.

Keep work running without tying up the prompt#

A long-running procedure shouldn't force you to choose between waiting at the prompt and losing track of its result. Repeated work also needs a defined lifecycle, not another forgotten terminal.

Builds with Rubian's job commands let you start named Ruby work, inspect its state, retrieve results and cancel it. Recurring-work commands add definitions, last results and explicit enable, disable and restore controls. These make it possible to distinguish running work from failed or completed work.

A background check can run while you inspect something else, then return its result when you're ready. Background jobs and recurring definitions have different lifetimes; restoring a definition isn't resuming a process from the instruction where it stopped.

Read Background jobs and Recurring work.

Give people and programs a place to work#

Several people or programs working on the same machine need identity, a working location and a way to exchange results. Sharing a terminal transcript doesn't supply those things.

Rubian provides accounts and access controls. Configured agent environments add callable workspaces, lifecycle controls and messages; collaboration services provide shared files and work records. A person can organize a project and a program can interact with the configured environment through an explicit interface.

This supports work exchange without pretending that every participant has the same role or permissions. Creating an agent workspace doesn't connect an AI provider by itself, and delivering a message doesn't establish that its requested task finished.

Read Accounts and permissions, Agent workspaces and Shared work and messaging.

Find out what's running and where it failed#

A Ruby job, a host process and an agent workspace aren't the same object. Trying to inspect or stop one with the wrong control adds confusion during an incident.

Taskman and the inspection commands expose different views of active work, memory, storage and logs. Networking tools help distinguish a local problem from a failed connection and provide routes for remote access and file transfer. The relevant guide identifies which object each operation affects.

Start with the process or job you can identify, inspect its observations and logs, then investigate connectivity if the work crosses machines. Missing or old observations shouldn't be mistaken for a healthy system.

Read Taskman and process control, System and storage inspection, Networking and file transfer and Troubleshooting.

A restart needs limits and a recovery plan#

Restarting a failed service is easy. Deciding how long to wait, how often to retry and when to stop is the harder operational problem. A deployment also needs a way back when its health check fails.

The Kestowv enterprise pilot supplies service supervision with health checks, retry budgets and backoff, plus versioned release operations and rollback. Its configuration can declare resource limits using supported host controls. Logs and release state provide evidence for investigating what happened.

Use these controls to define the expected response before running the service: what counts as healthy, which resources it may consume and which release to recover. Enforcement depends on the supplied Linux environment and delegated permissions; a valid configuration alone doesn't prove those controls are active.

Read Services, releases and recovery and Pilot configuration.

Know whether a machine-level change actually helps#

A busy CPU or a faster-looking run doesn't tell you whether a system completed more useful work. Inputs, correctness, latency and failed runs can change the meaning of a throughput number.

The Kestowv pilot supports declared workloads, baseline-versus-candidate comparisons and sustained runs. You set the workload and acceptance criteria, run the comparison and inspect the results. That gives an infrastructure engineer a concrete way to judge a change on a named machine under stated conditions.

The comparison doesn't manufacture a performance gain. Energy savings require energy measurements; reliability claims require appropriate failure and recovery tests. A result belongs to the workload and configuration that produced it.

Read Workload evaluations, Prepare a Kestowv pilot and the pilotctl command reference.

The problems we're researching next#

Kestowv's execution research asks how machines can complete more useful work under contention, and how coordination affects throughput, latency and energy per correct result. Work on heterogeneous resources examines a further question: how should different kinds of compute participate in the same system? Those are research questions with configuration-specific evidence, not a claim that every Rubian command is faster or every machine uses less energy.

The integrated OS projects bring a broader set of problems into scope. Arcturus targets enterprise and data-center environments; Valux targets a single PC or home cluster. Their intended predictive-maintenance capabilities address machine health and, for Arcturus, relationships across the data-center stack. The integrated operating systems remain in development, and the current public Arcturus demonstrations use sample data.

Explore Kestowv research, the benchmark methodology, Arcturus documentation and Valux documentation.

Start with your problem#

If one of these matches the work in front of you, follow its manual or discuss an evaluation. Tell us what runs today, what gets in the way and the result you need to measure. We'll use that to choose the relevant component and evaluation scope.