No classic Linux desktop to maintain. The platform is rendered full-screen by a hardened browser, on a minimalist graphics compositor. The user environment is AI-generated and optimized for this single display mode. Boot time is about ten seconds on a standard machine.
About fifty machine capabilities — screen, files, audio, Wi-Fi, camera, microphone, clipboard, isolated web sessions, on-demand admin access — are made available directly inside the platform page, without going through the network. The contract is strictly aligned with Boréal for Windows: agentic applications are portable between the two.
The same system can, from the interface, switch from a client role to that of a local ProductivIA host — to serve the platform to a team, a class, or an entire organization. If the hardware allows it, Matania can be served alongside the platform.
Recent LTS Linux distribution, stripped of the superfluous — no desktop environment, no package manager that can be manipulated from the machine, no third-party service left in place "just in case." The disk image fits within a few dozen gigabytes and follows a simple partition scheme, identical across every deployment of a given version.
A modern, single, linear boot chain — one path, hidden from the user, leading straight to the graphical session. No menu, no dual-boot, no legacy mode. The simplicity of this chain is itself part of the product's security posture.
A lightweight compositor chosen to do one thing: display a full-screen window of the platform. Automatic detection of the available GPU (NVIDIA, Intel, AMD), with a sensible selection priority and a software fallback mode when no native 3D accelerator can be used.
A recent Chromium-family browser, preloaded into memory at boot to reach the platform in about ten seconds. Started in a deliberately restrictive posture: it is the execution environment for the ProductivIA application layer, and nothing else.
Full-screen boot into ProductivIA, host capabilities injected into the page, persistent user profile. This is the workstation mode.
Server mode is explicitly activated from the interface. The machine then serves the ProductivIA platform locally, without depending on a third-party machine or a general-purpose server OS.
If a compatible GPU has at least 16 GB of dedicated memory, Matania can be served alongside the platform locally. Below that threshold, the server still works and delegates inference to remote resources.
In client mode, the machine listens on nothing at all on the outside network. The capabilities exposed to the platform travel through channels internal to the machine, and only a supervision endpoint can be voluntarily activated by the administrator. No server service is opened until the user has explicitly decided to do so.
Server mode, activated from the interface, then opens — and only then — the network surface needed to serve the platform to the organization's other machines. The client's restrictive posture remains the default; the server role stays a conscious choice, not a latent state.
At the heart of the system: a service that takes the machine from the boot screen to the platform, full-screen, in a few seconds. Automatic restart in case of an incident, fallback diagnostic mode if a critical step fails.
An internal access point, disabled by default, that allows — when activated — an internal supervision tool to observe the machine's state from the local network. Token-protected, closable at any time.
An event-driven mechanism that synchronizes, on every significant change, the user profile the session keeps in RAM to disk. An abrupt shutdown causes no loss of state and no database corruption.
The remote admin access point stays closed by default. It can be opened on demand, for a set duration, after which it closes itself.
Capture of the whole desktop or a specific area, reading of the current window's bounds. This is what gives the agent vision of what is on screen.
Browsing the user's file system, reading, writing, moving, copying, deleting — with systematic protection of sensitive system locations.
Running a local command, moving the mouse the way a human would, typing text, triggering a keyboard shortcut.
Discovering available audio outputs, choosing the active output, adjusting volume, muting, testing the audio chain.
Listing adapters, scanning available networks, connecting, disconnecting, reading the current state.
Enumerating devices, capturing an image, listing microphone inputs, recording a test sample.
Checking the admin access state, opening it for a set duration, closing it on demand.
Opening an isolated browsing session, navigating, capturing its result, closing it — useful for agents that need to act on another site without interfering with the user's own.
Going full-screen, reading the current window's bounds, reading and writing the clipboard, opening a private window on demand.
A classic access path to these capabilities would go through a network service that any program could theoretically talk to, requiring an authentication mechanism to design, maintain, and harden indefinitely. That means a cumulative attack surface, and the risk that a third-party page in the browser — an ad, an iframe, embedded content from another site — ends up calling these capabilities without anyone knowing.
The approach taken here reverses that logic. Host capabilities do not live on the network: they are injected directly into the platform page, through a local mechanism that only the browser on the local machine can activate, and only for explicitly recognized domains. A third-party page does not even need to be denied access — as far as it is concerned, the interface simply does not exist.
The same agentic capabilities, added on top of an existing Windows install. The usual environment is kept — along with everything that comes with it: constant telemetry, imposed updates, several gigabytes of system services, long boot times, inherited attack surface, unavoidable cumulative drift. This is the right entry point for evaluating the platform without changing OS.
The same agentic capabilities, on a system designed to carry them. No Windows layer between the platform and the machine. No outbound telemetry. No imposed updates. Boot time of about ten seconds. Attack surface reduced to the mission. Boréal OS can stay a client or become a ProductivIA server from the interface. And, on a machine with a compatible GPU, Matania in local residence — inference becomes a system service. The gap between the two is philosophical and architectural, not functional.
The surface offered to the platform is strictly the same on Boréal OS and on Boréal for Windows. Everything an agent can do on one side — see the screen, read or write files, control the browser, handle audio, the camera, the network, the clipboard — it can do on the other, with the same response contract.
A few details differ in the background: the system identifies itself to the platform as "Linux" or "Windows," letting an application adjust a handful of surface conventions (path separators, keyboard shortcuts). On the current version of Boréal OS, a handful of interactions do not yet have a native equivalent under the graphics compositor in use and are handled through a fallback mechanism; the platform takes care of it without user intervention.
The practical consequence: an application developed for the agentic ecosystem works equally well on either distribution. The choice between Boréal for Windows and Boréal OS is therefore not about what the agent can do — it is about the system that carries it.
Once that contract is honored, the two worlds have effectively nothing in common. Under Boréal for Windows, the agentic layer lives on top of a third-party vendor's OS: constant telemetry, imposed updates, memory footprint and boot time inherited from the system, extended attack surface, unavoidable cumulative drift. The agentic ecosystem works fully there — it is a good entry point for evaluating the platform — but the operating system itself remains someone else's.
Under Boréal OS, the system was designed for this precise mission. No outbound telemetry. No silent updates: every version is a signed image adopted at its own pace. Memory footprint and boot time reduced to the strict minimum, with the rest of the machine going to the platform and, if enabled, to Matania in residence. A reduced, documented service surface. Hardening produced through agentic passes under human supervision, and the guarantee that every machine on a given version is strictly identical at any point in time — which makes diagnostics and support immediately scriptable.
Boréal OS is also where a client switches to a server role — to serve the platform to an entire organization from its own premises — and where Matania can run locally when the machine has the necessary GPU. Bottom line: to use the platform, Boréal for Windows is enough; to align the OS itself with requirements of privacy, sobriety, non-obsolescence, and sovereignty, Boréal OS is the only consistent option.
Exist only inside the machine, injected into the platform page. No network surface is opened to expose them, no third-party service can connect to them, and no page other than the platform's own can reach them.
If activated, an internal access point becomes reachable on the local network, protected by a token to regenerate in production. Deactivatable at any time.
Available strictly locally, and proxied through the supervision channel when it is open. No additional port is exposed directly on the network.
Closed by default. Activatable for a set duration, with automatic closing. More details in the FAQ.
Recent NVIDIA cards (GeForce, Quadro, RTX) — priority driver built into the image.
Integrated GPUs and modern Intel cards (Skylake and beyond, Intel Arc).
Recent AMD Radeon (RDNA) and legacy.
Software fallback mode available when no native 3D driver can be used.
Ethernet: virtually any card supported by recent Linux 6.x kernels.
Wi-Fi: common Intel, MediaTek, Realtek, Atheros, and Broadcom adapters, on WPA2 and WPA3.
Simple, deterministic audio chain, with no intermediary daemon. Common integrated, USB, and HDMI sound cards. Default preference for the machine's analog output.
Standard USB UVC webcams and integrated laptop cameras. Microphones listed and individually testable, with a CD-quality test recording.
Standard USB and PS/2 devices, Bluetooth if paired outside the platform. Synthetic typing and clicking available through agentic capabilities. Common touchscreens natively supported.
NVMe, SATA (SSD and HDD), eMMC. During installation, removable devices and the disk the system is currently running from are systematically excluded from the list of candidate targets.
During the session, the browser profile — history, cookies, local data — lives entirely in RAM. Instant responses, no stray disk writes, no cumulative fragmentation.
When something that needs to persist changes, the system copies it to disk in an atomic format: write alongside, then swap in. An abrupt outage never leaves a corrupted file behind, and the session restarts cleanly next time.
Matania observes local usage, tunes the system, and handles everyday inferences — summarizing, rewriting, reading an image, analyzing a document, generating short text. No data needs to leave the machine for these tasks. When a request exceeds its capabilities, it switches to orchestrator and delegates to a partner provider, if that option is chosen.
In server mode, and with a hardware target of at least 16 GB of dedicated memory, Matania can be served to the entire organization from the same host as the platform. Coherence becomes vertical: one machine serves both the application and the model, and everything stays within the perimeter.
No host capability exposed on the network. Authorized origins explicitly listed. Remote admin access closed. Remote supervision disabled by default, token to regenerate if activated.
Text confirmations required for any destructive operation. Systematic validation of requested origin and paths. No bypass possible from a third-party page or embedded frame. No outbound telemetry from the browser or the system.
Hardware compatibility, security, updates, supervision, server mode, local execution of Matania.
Complete procedure: preparing the USB stick, BIOS, installation, first boot.