Common SBOS questions

No. SBOS had an early Linux-based prototype and research period. Current SBOS is a proprietary desktop and server operating system, not a Linux distribution.

A native SBOS application uses a .sba bundle. The bundle is the stored application package. SBOS validates it, reads its manifest, registers it in the SBOS App Registry, materializes the runtime environment, attaches app-local dependencies and permissions, then starts the app.

The SBOS App Registry is the operating system record for application identity and lifecycle state. It can track versions, hashes, package and runtime locations, ownership, permissions, profiles, updates, diagnostics, movement, removal, repair, reset, and recovery. It is not the Windows Registry and applications do not use it as a general-purpose settings store.

SBFS is the Star-Blade File System. It handles immutable system and core files, system state, application state, user data, snapshots, rollback, recovery, integrity information, and storage-efficient inactive application environments.

Supported Windows applications use a Windows-oriented compatibility path. SBOS identifies PE files, .exe files, .msi packages, installers, launchers, updaters, version declarations, runtime expectations, and metadata before selecting or creating an app-specific environment.

Supported Linux and macOS applications use separate compatibility paths. Linux handling can use ELF, .deb, .rpm, distribution-family metadata, library expectations, and service assumptions. macOS handling can use Mach-O, .app bundles, property lists, bundle metadata, and framework expectations.

No. Windows, Linux, and macOS applications do not become .sba applications. They are registered and managed by SBOS through compatibility environments that remain separate from the native .sba application model.

An app environment is the application-specific runtime state SBOS prepares for an app. It can include files, dependencies, configuration, permissions, devices, network rules, resources, compatibility behavior, diagnostics, reset, repair, recovery, and clean removal state.

When an installer opens, SBOS identifies the platform and file type, runs the installer inside the application environment, observes the installation, identifies the installed application, registers it, and keeps its files, dependencies, configuration, services, caches, and local state within that environment.

Application dependencies remain associated with the application environment. Native applications and compatibility applications do not scatter dependencies throughout the operating system as an application-controlled installer would on a traditional system.

Not by default. Applications cannot freely list unrelated processes, inspect unrelated process memory, or edit unrelated process memory unless SBOS grants explicit authority. A memory editor does not automatically receive access to another app merely because both are running.

No. User files are provided through a file picker, explicit permission, User Policy, or administrator rule. Application files, dependencies, caches, and settings remain associated with that application.

Applications can receive separate network views and policies. Outbound access, inbound access, localhost visibility, and app-to-app networking can be controlled per app.

No. SBOS diagnostics are system-focused. They cover faults such as crashes, invalid states, freezes, performance faults, dependency failures, API translation failures, compatibility events, system health, and application lifecycle failures. They are used for compatibility, stability, security, and fault analysis.

Adult, Teen, and Kid are local SBOS account categories used for User Policies and suitable defaults. They are not identity-verification categories. When an application requires a date of birth, SBOS provides a stable randomized compatibility date appropriate to the category unless the user or policy explicitly provides a real date.

TPM and comparable secure hardware are supported and used where available, but TPM is not universally mandatory. SBOS can operate on supported hardware without a TPM. Available trust features vary with hardware capabilities.

SBOS supports a range of desktop and server hardware. Exact support depends on the SBOS release and the device, driver, GPU, controller, VR, firmware, and TPM combination.

Gaming is an SBOS Desktop use case. Games and launchers use the same compatibility-environment architecture. Support varies by game, launcher, anti-cheat system, and version.

Anti-cheat-sensitive software can use compatibility profiles, brokered permissions, administrator policy, and supported execution paths. Applications do not receive unrestricted authority over the SBOS host merely because they expect deep Windows access.

No. SBOS application environments are separate from full virtual machines. Normal apps do not each run inside a full VM. The SBOS native hypervisor is used for full virtual machines.

No. VMware and VirtualBox are separate third-party compatibility applications. Supported versions vary by SBOS release, and they do not participate in native SBOS trust inheritance. In eligible volume-licensed deployments, an SBOS guest can inherit host trust and licensing only through the SBOS native hypervisor.

FST ID is the SBOS identity and directory system for users, groups, devices, services, applications, organizational units, policies, certificates, enrollment, SSO, federation, delegated administration, LDAP compatibility, Kerberos compatibility, RADIUS, and migration or coexistence with existing directories.

Star-Blade Gateway Services, or SBGS, combines a required policy, routing, and firewall core with optional services for proxying, DNS controls, filtering, inspection, malware analysis, VPN, remote access, traffic management, service chaining, health, dashboards, and FST ID integration.

SBN is the Star-Blade Network protocol and services model for network file sharing and related network resources. It is comparable in role to SMB or NCP. SBN is not SBFS.

SRWECMFA is the SBN trustee-rights model: Supervisor, Read, Write, Erase, Create, Modify, File Scan, and Access Control. Supervisor is the highest SBN trustee right inside the applicable SBN share or file-tree scope. It is not SBOS root access.

Updates are staged separately from active system state, validated before commitment, and applied through the SBOS update process. SBOS does not leave the system in a partially updated state, and rollback or recovery paths are available.

Server Suite is the administered set of SBOS server capabilities. Its roles can be deployed together or separately according to required server duties.

An App Collection is a managed set of related server components. It can define required and optional services, dependencies, identity, networking, storage, policy, lifecycle, updates, health, diagnostics, dashboards, isolation, and failure handling as one administered unit.

No. SBOS is currently privately distributed and is not publicly downloadable. This site documents SBOS; it does not provide downloads.