<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Linux on Ownchain Systems</title>
    <link>https://ownchain.systems/tags/linux/</link>
    <description>Recent content in Linux on Ownchain Systems</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 30 Aug 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ownchain.systems/tags/linux/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CODEX-001: Decommissioning Socket-Mounted Web UIs &amp; Enforcing Terminal-Native Ops</title>
      <link>https://ownchain.systems/codex/001-socket-hardening/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/001-socket-hardening/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Ingress Hardening &amp;amp; Attack Surface Reduction&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report documents the architectural lifecycle of container management on Bastion: from initially deploying a web-based GUI (Portainer) to overcome early CLI friction, to identifying the inherent security risks of host-socket mounting, and finally decommissioning the interface in favor of key-authenticated, terminal-native tooling (&lt;code&gt;lazydocker&lt;/code&gt;).&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;phase-1-initial-deployment--context&#34;&gt;Phase 1: Initial Deployment &amp;amp; Context&lt;/h2&gt;&#xA;&lt;h3 id=&#34;why-portainer-was-introduced&#34;&gt;Why Portainer Was Introduced&lt;/h3&gt;&#xA;&lt;p&gt;When initially transitioning to Docker and container orchestration, early CLI management presented significant friction. Debugging multi-container networks, diagnosing container start failures, and managing persistent volume paths purely through raw shell commands often led to silent errors and operational overhead.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-005: Sandboxing vs. Storage Vaults: Flatpak, AppImage, and Native Packaging</title>
      <link>https://ownchain.systems/codex/005-sanbox-storage-boundaries/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/005-sanbox-storage-boundaries/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Filesystem Security &amp;amp; Runtime Sandboxing&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report analyzes permission boundaries, filesystem isolation, and execution failures encountered when integrating sandboxed application formats (Flatpak and AppImage) with external storage vaults (such as &lt;code&gt;/mnt/lacie&lt;/code&gt;). It details the diagnostic triage of permission denials, FUSE execution restrictions, and the decision to standardize core system tooling on native package management.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model--problem-statement&#34;&gt;Threat Model &amp;amp; Problem Statement&lt;/h2&gt;&#xA;&lt;p&gt;Application isolation frameworks (Flatpak, AppImage) provide sandboxing by restricting default access to the host filesystem. However, when operational workflows require direct access to designated storage mounts, isolated runtimes introduce specific operational failure modes:&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-006: Hybrid GPU Provider Synchronization &amp; GUI Kernel Recovery</title>
      <link>https://ownchain.systems/codex/006-hybrid-gpu-kernel-recovery/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/006-hybrid-gpu-kernel-recovery/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Kernel Architecture &amp;amp; Display Subsystem Recovery&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report covers root-cause diagnosis, driver stack reinstallation, and display provider synchronization on a hybrid graphics architecture (Intel Core i9-13900HX / NVIDIA RTX 4090 Mobile) running under non-systemd (Artix) Linux with XFCE Desktop Environment. It details the recovery protocol following a desktop environment collapse (corrupted font/theme subsystems and session manager crashes) and the resolution of &lt;code&gt;xrandr&lt;/code&gt; discrete output provider drops.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
