@ghita

devlog #2

devlog 1 ended with four fake satellites orbiting an empty earth. it worked, but it felt kind of hollow on its own.then i saw a screenshot of an app called conflictly, a dense dashboard tracking conflicts in real time. i had a “wait, what if this but for space” moment, real launches, real satellites, real news, not just my sim.

so i built a python backend pulling real data, launch library 2 for launches, spaceflight news for headlines, celestrak tles propagated with skyfield for the iss, tiangong, and hubble. cached, resilient, never crashes even when an upstream api sends garbage.

then i turned it into an actual ops floor look. countdown to the next launch, a breaking news ticker, launch pads that light up and pulse when live, real spacecraft shown as white rings so you can tell them apart from the sim satellites. two clocks, real utc and the sim fleet still running at 60x.at some point i realized the real world tracker and the simulated fleet were fighting for the same screen, so i split them into two modes you can flip between, one for the real sky and one just for the starcloud fleet with its own roster and telemetry.

last pass was small stuff that matters in daily use, color that actually means something instead of just looking nice, and making the launch pad dots easier to click with a hover grow effect.started as watching four fake satellites. ended up blending real live orbital data with a simulated glimpse of what training ai in space could look like.

happy with where it landed

devlog #1

so this started because i read a white paper. not something i do every day, but i came across the starcloud/lumen orbit paper called “why we should train ai in space” from 2024 and i couldn’t stop thinking about it. the idea of orbital ai data centers, satellites doing machine learning in low earth orbit, solar power that never turns off, no cooling costs. it just clicked something in my brain.

i spent probably the first hour just reading and taking notes. what would it actually look like to monitor something like that? like if you were the person watching these satellites, what would your dashboard show? solar power, battery percentage, radiator temperature, whether the satellite is in sunlight or in eclipse. and then the orbit itself, the actual position over the earth in real time.

so i decided to build it. a full mission control dashboard, the kind nasa uses, except for a simulated version of what starcloud might actually run. i picked open mct which is nasa’s open source mission control framework, and started building on top of it.

five hours in and i’ve got more done than i expected. there’s a telemetry server running in python that simulates four different satellites with real physics, power generation, battery charge/discharge, thermal modeling. the frontend connects to it live over websockets and plots the data in real time on an accelerated simulation clock so you can actually watch the orbit happen.

the thing i’m most excited about right now is the 3d globe view i just started. you open a satellite in the dashboard and you get a realistic earth with the satellite orbiting it, colored gold when it’s in sunlight and dim blue when it’s in eclipse. that part isn’t done yet but the bones are there.

more to come soon

Devlog 3 - DevBox becomes 0xKit

Big pivot. DevBox is turning into 0xKit, a toolkit for CTF recon, crypto and forensics. Same offline browser app, sharper focus.

The honest reason: DevBox worked, but it was a pile of converters you could find
in ten other places. No reason to reach for it. So instead of bolting on more
generic tools, I pointed the whole thing at one user, a CTF player, and built
the harder tools that crowd actually needs.

What sold me on the pivot was realising DevBox’s “nice to have” is a real selling point here. Everything runs in your browser and never leaves your machine. For a dev formatting JSON, who cares. For someone poking at competition data they shouldn’t paste into a random website, that matters.

The centerpiece is a pipeline. Instead of one tool per page, you stack operations and each feeds the next: From Base64, then From Hex, then XOR. It’s the CyberChef idea, rebuilt small and dependency-free. Underneath, every operation speaks one language, raw bytes, so a gzip blob survives the chain instead of getting mangled. Building it meant writing things by hand you’d normally install: MD5, SHA-1, a base58 codec with a sneaky all-zeros bug a test caught.

So was it worth it? Yes. 0xKit has a point of view now, it’s for someone instead of being a drawer of odds and ends. And it forced real work: a composable engine, hand-rolled crypto, a pile of tests. I even cut JSON, color and cron to commit to the bet. Felt scary, then immediately right.

Next up: the Magic button, which guesses the decode chain for a blob you don’t understand, then the crypto and forensics tools, and getting 0xKit live.

Devlog 2 - Four more tools and search

DevBox grew up a bit this round. It went from three tools to seven, and the sidebar finally got a search box.

The new ones: Regex tester, Timestamp converter, Color converter, and Text Case. The Regex one is my favorite - it highlights matches live as you type and counts them, with the g/i/m flags as little checkboxes. Timestamp figures out on its own whether you handed it seconds or milliseconds. Color swaps between HEX, RGB and HSL and shows a swatch. Text Case turns whatever you type into camelCase, snake_case, kebab-case and the rest.

Now that the list was getting longer, I added a search box up top - just start typing to filter, or hit Ctrl+K to jump straight to it.

The fiddly bits were the small edge cases. Regex with something like \d* used to duplicate the text in the preview, and the case converter choked on acronyms like parseHTTPRequest. Both fixed now. Boring stuff, but it’s the difference between a toy and something you actually trust.

Next up: a hash generator, and making the whole thing work offline as an installable app.

Devlog 1 - Getting started

My first devlog! DevBox just went from an empty folder to something I can
actually use, with three working tools.

The idea: one page with all the little tools devs keep googling - JSON, Base64,
URL encoding - running right in your browser. No submit buttons, works offline,
nothing you type ever leaves your machine.

I started with the shell, so adding a tool is dead easy: one folder plus one
line in a config file gets it into the sidebar, routing, and search. Then the
first three tools - JSON Formatter, Base64, and URL, the last two auto-detecting
whether to encode or decode.

The tricky part was that auto-detect: it only treats input as Base64 if it
survives a clean round-trip, otherwise plain text turns to garbage.

Next up: four more tools (Regex, Timestamp, Color, Text Case).

last one for this round, added a theme switcher to the desktop. there’s a new [*] button in the taskbar that cycles through three color schemes: ember (the original orange, default), phosphor (green, classic crt terminal look), and cyber (blue). clicking it swaps the accent color across the whole desktop. window borders, highlights, the terminal cursor, and even the living mascot’s glowing eye all shift to match, since they were already built on a shared accent
variable.

it resets back to ember on reload, so you always start from the default look.

architecture-wise this was a clean one to slot in. the theme logic is a small standalone module (just a list of themes and a “next theme” function), same pattern as the window manager and mascot logic, so it’s unit tested without needing a browser.

quick one - made the repo public today and set up a live demo, so now you can actually try embercrow os in the browser instead of cloning it.

demo: https://andreirazvanghita.github.io/embercrowos-stardance/
repo: https://github.com/AndreiRazvanGhita/embercrowos-stardance

it deploys automatically through github actions, so whenever i push to master the live version updates within a minute or two. nothing new functionality-wise, just wanted it accessible for anyone who wants to poke around without setting up a local server.

ok so this is my webos mission entry. theme is basically “what if a hacker terminal and a desktop os had a baby” - black and white everything, one accent color (ember orange), monospace fonts, the works. no frameworks, just html/css/js because i wanted to actually understand every line of this thing.

got the core stuff working:

window manager - you can drag windows around, focus them (the active one gets a glowy orange outline, felt very “hacker movie” to me), minimize to the taskbar, close them. double click an icon and it spawns a new window, slightly offset so they don’t all stack exactly on top of each other.

apps - went with 5:

• a terminal you can actually type into (help, whoami, ls, etc, plus a hidden crow command that prints an ascii bird because why not)
• a fake file explorer with a little folder tree (there’s a secrets.txt in there, very serious business)
• an “about” app that’s basically neofetch but for my os, shows uptime and stuff
• a notes app that saves to localStorage so your notes survive a refresh
• a music player with a little audio visualizer using the web audio api - this one took way longer than expected

the boot sequence - probably my favorite part. when you load the page you get a fake terminal boot log scrolling by ([ ok ] mounting //embercrow/root… type stuff), then this big ascii bird silhouette fades in with a glowing orange eye, then a fake login prompt types itself out and “logs you in” (no actual password, it’s all for show), then it does a crt scanline transition into the desktop. you can skip it by pressing any key if you don’t want to sit through it every time.

the mascot is “the embercrow” - giant bird of prey made out of dots/ascii blocks with one glowing eye. shows up in the boot sequence and as a little taskbar icon.

architecture-wise i kept the window manager totally dumb/generic - it doesn’t know anything about specific apps, each app just registers itself with a title, icon, and a function that builds its content. made it way easier to build each app on its own and test it in isolation.

todo

mostly polish at this point - tweaking the boot sequence timing, maybe a couple more terminal easter eggs. core stuff is done and working.