ARK-OS

ARK-OS is a project built on the linux kernel and using swift.

It its still under early developemnt but right now it boots Up and gives out ormal comend line output! Much more still is pending since it is under early developmet but the core is there.

why linux + swift?

• linux gives it a rock-solid base that works on hardware out of the box
• swift makes the system apps fast and memory safe without the headaches
• no bloat is the main rule because every component needs to earn its place

Repository is self hosted due to github limits (on a oracle server)

https://github.com/Aarav90-cpu/Oneplus-7---Unlocking-the-Bootloader

This guide shows how to unlock the bootloader while providing the files to do it!

<WRITTEN BY A HUMAN>

>

Introduction

I know... the pain... torture of unlocking a bootloader on a Oneplus 7 since I have been through it 2 times!

See if you have a Oneplus 7 stuck on the Stock OS of ANdroid 12 you cannot unlock it since the unlocker is basically broken!

This guide gives you a step-by-step instruction on unlocking it!

ARK-OS

A BOOTLOADER+KERNEL+GUI Giving Custom OS. (ONLY SUPPORT 14-gr0000TU [KERNEL])

BootLoader

• Shows ARKOS logo with white background
• Press ESC key to enturrupt boot and get into:

<img width="513" height="315" alt="image" src="https://github.com/user-attachments/assets/c9f56459-5988-410d-b8a1-425e7c8b66bd" />

Issue: Function Keys Do NOT WORK... USE number keys!

KERNEL

• I able to Locate Simple File System and LOad Kernel Segmennts
• It gets stuck building bootinfo

Also it does not know what is anything... it is only made to do that and display a green screen showcasing that I am ready for the next phase but unable to get there yet!

GUI

• After the kernel is done booting it will hand it of to the GUI [I am saying GUI since it is a simple word for non techies to understand] WHich is just a bunch of empty folder since i have do nnothing for that yet but here is the tree:

  OS ├── Applications │ ├── AI │ ├── Browsers │ ├── Cloud │ ├── Devlopers │ ├── Entertainment │ ├── Social │ ├── Study │ └── Utilities ├── System │ ├── <APPNAME>.cache │ ├── Drivers │ └── Logs └── User └── USERNAME ├── Desktop ├── Documents ├── Downloads ├── Music └── Photos ├── Camera ├── Screen Records └── ScreenShots

Well it is just a package manager! Nothin else!

✨ Expressive Glass

>

A Jetpack Compose UI library that fuses Material Design's bold, expressive visual language with Apple's physics-driven interaction model. Every component looks Material Expressive and feels like Apple's Liquid Glass.

   

DEMOVIDEO = https://github.com/Aarav90-cpu/Expressive-Glass/blob/main/DEMOVIDEO/expressgl_demo.mp4

Hey everybody

So I’ve been doing an experiment in operating systems. I'm trying to make a Linux kernel environment where you can develop programs using Kotlin. This is a completely sandboxed environment. It does not require any other programs to run.

When the Linux kernel starts up, it usually hands control to a program that helps get things going. This program contains a lot of C code and bash scripts. I wanted to see if I could kill all of that and only use Kotlin.

Instead of a standard root filesystem, I wrote a Kotlin program and compiled it ahead-of-time into a statically linked linux_x64 binary using Kotlin/Native. By passing init=/init.kexe in the kernel boot parameters (via QEMU), the Linux kernel hands control directly to the Kotlin executable as PID 1.

From there, Kotlin is completely in charge of the system lifecycle:

1. Filesystem Mounts: Using kotlinx.cinterop, the Kotlin script natively executes raw POSIX syscalls to mount /proc, /sys, /dev, and creates a tmpfs RAM disk over /tmp (which Java/Gradle requires to unpack JNI libraries).
2. Network Stack: Because we bypassed standard networking daemons, the Kotlin init process has to manually fork and configure the loopback interface (lo) and the ethernet interface (eth0), assign static IP routes, and securely bind-mount a custom /tmp/resolv.conf over the host's DNS configuration to establish internet connectivity. ( QEMU ETHERNET ONLY )
3. The Build Pipeline: The repository acts as its own root filesystem via a virtio-9p passthrough. We embedded a standalone OpenJDK and the Android SDK directly into the kernel tree.

Once the Kotlin init process stabilizes the network and mounts the filesystems, it dynamically injects the environment variables (JAVA_HOME, ANDROID_USER_HOME) and forks a child process to launch the Gradle Build Daemon.

The system successfully resolves dependencies from Maven/Google, orchestrates the build cache, and compiles a native Android application (kernel.kotlin.system) directly from the Linux boot loop. If there is no ethernet the build fails and you continue on without kernel panics!

Also it comes with a package manager at kernel level!
When you boot up and have internet/ethernet access just run kotlib sync!

It’s completely standalone, bypasses standard Linux userspace utilities entirely, and proves that Kotlin/Native is robust enough to handle low-level POSIX environment orchestrations.

ArkCode

ArkCode (.arkc) is an ultra-fast, "easy as hell" minimalist programming language designed for rapid application and UI development. It merges the clean block-builder syntax of Kotlin and the simplicity of Python.

Core Tenets

1. Speed & Ease: Parsing and compilation is powered by the aake compiler, written entirely in C++ for maximum speed.
2. Minimalist UI/DSL Builders: Clean, anonymous code blocks with builder patterns.
3. No Boilerplate: No main classes needed for scripts.

The Compiler (aake)

The ArkCode compiler/interpreter is built in C++

🚀 LightBase

Ultra-performance, bare-metal local development runtime bridge and persistence engine built for high-compute applications.

LightBase decouples heavy disk and outbound network I/O into a standalone, multi-threaded C background daemon, communicating asynchronously with an API gateway over high-speed Linux Unix Domain Sockets (UDS).

🏗️ Architecture Layout

LightBase eliminates high-level framework overhead, garbage collection cycles, and process-blocking runtime constraints by decoupling tasks into independent layer boundaries.

graph TD
    UI[HTML5 Control Center UI] <--> PY[Python Gateway Bridge Server]
    PY -- "Binary TLV Frame Stream (/tmp/lightbase.sock)" --> CORE[C-CORE ASYNC THREAD POOL]
    
    subgraph "C-CORE (libcore.so)"
    CORE --> R1[Arena-Powered SQL Engine]
    CORE --> R2[Stack-Isolated OpenSSL TLS]
    CORE --> R3[Kernel /proc Ring Log Storage]
    CORE --> R4[Database Catalog Scanner]
    end

Layer Responsibilities

• Frontend UI Layer: A lightweight development client executing async network operations back and forth.
• API Gateway Layer: A zero-dependency Python routing engine acting as an IPC proxy gateway.
• Native Systems Core: A high-speed, bare-metal C shared engine processing dynamic allocations, filesystem transactions, and socket forging loops on detached POSIX background threads.

🚀 Core Studio Module Suite

🌐 Module 1: Bare-Metal Environment Manager

Tracks application environments (Development, Staging, and Production) dynamically inside isolated runtime boundaries.

• Atomic Remapping Swaps: Eliminates sluggish filesystem configuration lookups by pre-allocating an EnvironmentBlock structure directly within a dedicated MemoryArena. Context switches occur in under 1μs via thread-safe atomic pointer reassignments.
• Fallback Safety Paths: System state transitions are fully guarded against uninitialized pointer exceptions, ensuring backup file parameters handle initial transaction states safely.

🧪 Module 2: Cryptographic API Testing Studio

Provides bare-metal HTTP engine request assembly and transaction benchmarking.

• Wire Packet Serialization: Leverages stack-allocated sequence spaces to assemble raw wire payloads (GET, POST, PUT, DELETE) with exact specification alignment.
• Memory Security: Replaces vulnerable variable concatenation with explicit length-bounded tracking (strncat), preventing string overflows when importing large custom data tokens.

🗄️ Module 3: Log-Structured Database Explorer

Powers interactive sidebar schema catalog visualizers and data grids.

• Catalog Data Harvesting: Bypasses table-scanning bottlenecks by executing targeted schema scans directly against the internal engine catalog (sqlite_master).
• Tele-Profiling: Measures precise VM bytecode query times using high-resolution monotonic hardware timers (clock_gettime).

🗄️ Append-Only Ring Buffer Telemetry Storage

Ensures high-throughput execution tracking without destroying flash storage sectors.

• Static File Sizing: Pre-allocates a fixed array block file footprint on disk exactly once during system boot, guaranteeing predictable allocation.
• Wrap-Around Bit Algebra: Sequences incoming snapshots using sliding timestamp indexes. When the tracking pointer reaches limits (1024 slots), it wraps back to slot 0 instantly.

📊 Performance Benchmarks

LightBase delivers sub-millisecond core processing speeds by bypassing the local network routing stack:

• Local Database Transaction: ~990.20 μs ($< 1\text{ ms}$ bare-metal execution)
• Total IPC Roundtrip Gateway Latency: ~1.203 ms (Inclusive of Python decoding and HTTP transport)
• Outbound HTTP Network Socket Request: Variable based on distance, wrapped with microsecond-accurate tracking via CLOCK_MONOTONIC.

🛠️ Compilation & Installation

Prerequisites

Ensure your host machine runs a modern Linux kernel with cmake, gcc, and uv:

sudo apt update && sudo apt install cmake build-essential

1. Build the Production Core Library

LightBase employs an out-of-source CMake build pipeline with Link-Time Optimizations (-O3 -march=native -flto -s):

cd core
mkdir -p build_release && cd build_release

# Configure and build the target layout
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build . --target install

Assets generated:

• Public Header: dist/include/engine.h
• Shared Binary: dist/lib/libcore.so

2. Boot the Intermediary Python Gateway

cd ../../bridge
/usr/bin/uv run python python_bridge.py

The C-Core instantly carves out a high-speed memory socket at /tmp/lightbase.sock upon initialization.

🧠 Memory Design & Safety Assertions

• Header Symbol Ordering: Enforces a strict structure order: macro directives first, raw packed structural records second, and export function interfaces last to ensure top-down layout translation.
• Translation Scope Reductions: Centralizes cross-module variables within a shared master header file to keep dependencies clear.
• Thread Race Protection: Active server file descriptors pass explicitly into separate heap memory pools (malloc) at worker thread creation, isolating context pointers from stack invalidation faults.

📄 License

Licensed under Apache License 2.0

https://github.com/user-attachments/assets/a73a9aa6-7c3e-48c1-94fc-4ed1faee0ecd

The above Image is my current Progress please share your thoughts!

https://kommodo.ai/i/R904ypjyy4G0Yhk7aCvf

I am working on bringing Liquid Glass to C++

The above Image is my current Progress please share your thoughts!