fb03

omg, core memory unlocked

Also this is slop.

Is anything done with AI automatically slop? I don't understand this

The author's complaint is that omarchy is basically a set of ricing on top of arch. I can grok that

Problem is, some people are really impressed by ricing and that is what has been catching users for that ""distro""

I'm pretty sure the fans of minimalism/t distros or just plain bare setups aren't really hyping that much. The author is right in that it's just an opinionated layer on top of Arch

I am also (second post) working on an "idle clicker" like TUI game called "cuqueclicker", where you click an ass instead of a cookie (yeah, it's inspired by Cookie Clicker)

https://github.com/flipbit03/cuqueclicker

Runs locally and has binaries for every platform that matters out there, including a WASM port that saves your save data to local storage

WASM Port here: https://flipbit03.github.io/cuqueclicker/

Try it out! It's a fun little idle game

I'm working on a full blown terminal emulator called "terminal-use", or "tu" in short, for coding agents. It allows agents to operate fully fledged TUI applications including multiple windows, mouse control, etc. It can even self drive a NetHack session via Claude, if you want lol.

It's basically tmux for your coding agent, great for developing and debugging TUI applications as well, because now your agent has a closed feedback loop of applying changes and trying them out itself via tu.

https://github.com/flipbit03/terminal-use

Can you run the same tests on Qwen3.5:9b? that's also a model that runs very well locally, and I believe it's even stronger than Gemma2B

I'm working on `tu` (terminal use), which is a way to give agents access to a full blown virtual terminal to operate TUI apps

https://github.com/flipbit03/terminal-use

I'm super proud, because it came to my knowledge that someone at Codex used my tool to debug codex+zellij issues, by running zellij within `tu`, and then codex inside zellij

Outages are already happening, besides that, we need vibe warrooming

Quick Q: OP told he used Llama 3.2:3b which is a pretty old model. What would be a good modern model to substitute it? Qwen3.5:4b or something?

  Show HN: forestui – TUI for git worktrees with Claude Code + GitHub integration

  I built forestui to manage the chaos of working on multiple features/branches simultaneously. It's a tmux-powered TUI that orchestrates your worktrees, editors, terminals, and Claude Code sessions across organized tmux windows (edit:repo:branch, claude:repo:branch, term:repo:branch). Switch contexts without losing state.

  Why? Git worktrees let you have multiple branches checked out at once without stashing or juggling, but I find managing them with raw git commands painful.

  What it does:

  - Worktree management: Create, rename, archive, delete worktrees with single keypresses. Each worktree gets its own directory, so you can have feat/auth, fix/bug-123, and main all open in different editor windows simultaneously.
  - GitHub integration: Lists your open issues directly in the TUI (using the gh cli). See an issue you want to work on? One keypress creates a worktree with an auto-generated branch name (42-fix-login-bug) and optionally pulls latest first.
  - Deep Claude Code integration: Tracks sessions per-worktree, shows recent sessions with message counts and last activity, resume any session with one keypress. Also trigger Claude's YOLO mode for fast iteration in a wt using a single button press.

  Tech: Python 3.14, Textual for the TUI (app is fully reactive and works with mouse well), Pydantic for models, libtmux for tmux integration. Strict mypy, async everywhere so the UI never blocks.

  Install:

  # One-liner (installs uv if needed)
  curl -fsSL https://raw.githubusercontent.com/flipbit03/forestui/main/install.sh | bash

  # If you already use uv
  uv tool install forestui

  Auto-updates on startup via uv. Requires tmux and, optionally, the gh cli.

What a coincidence! I actually implemented a harness to test this, about a week ago

https://github.com/flipbit03/caducode

I've created a toy coding agent called "caducode". More of a thought experiment that materialized into a little something.

The philosophy behind it is: instead of providing a bunch of tools to the LLM, you simply provide a single tool: run_python(). The Agent just generates code to do whatever it needs, to inspect local files, to carry edits, to run commands.

https://github.com/flipbit03/caducode

It worked surprisingly well, even with a very small 30b local model.

"I'm using OpenAI here"

proceeds to show a piece of code importing anthropic

was pretty confusing to me

The only thing that still makes me maintain a Windows installation is playing League of Legends. Everything else (I mean, real work) is done on Linux

Yes, it was configured in his mRNA

Cracked me up good, thank you

In the homepage there's literally a link on the top bar called "Screenshots"

I think the next move is to not install Linux at all, completely impossible to mutate as it's not even existent? lol

I guess you sabotaged your own point with the answer. If it takes a full weekend to just have my DE look like what I feel is needed, that's a lot of time wasted that you could be doing useful work or even gaming, in that sense, idk. But to each their own.

I was a ricer before in my heydays of Linux, but now, after 25 years, I just use whatever comes by default with Xubuntu (XFCE) and a Macbook

Was about to mention this. 25y+ linux user here, we all had our ricing phase, where we'd customize our desktop and shell to oblivion. Now, I'm always on a as-vanilla-as-possible Ubuntu machine, or a Macbook with the same default wallpaper that came when I bought it.

The only thing I do to my new systems is installing oh-my-zsh, because that gives me a lot of goodies for basically zero configuration (I just use and learned the default presets to be "my own")

I don't think this would accidentally eat at Apple's laptop market because the laptop-in-a-stick option would still need an external screen. If you're travelling for work or something, might as well just have your phone AND your laptop, instead of phone + external screen full of messy cables. but YMMV

I'm still waiting for the apple laptop killer (a 12h+ laptop with plain Ubuntu) but it's still brittle as fuck. I'm so frustrated by the current state of the mobile computing space. I have to have an Apple locked down device, which I hate, just because I want proper battery life.

A aarch64 Ubuntu vm inside MacOS runs faster and lasts more time than a booted up Ubuntu on arm in these devices. This is how far behind these things are.

and what bums me the most is that it's all about software. The hardware is great, but software on Snapdragon is taking a lot of time to catch up and it screams M$ lobby to me

Well, we could FFI this into a scripting language for sure

Offtopic: This is awesome, but oh my god, my heart almost skipped a beat when I thought it would be Renoise itself going opensource. I've been tracking with Renoise for the past 14 years and I love it to bits.

Very curious to test this as well

Of course! In the PydanticAI docs for Agents, you have a fully defined example of a tool calling agent (roulette_wheel.py)

https://ai.pydantic.dev/agents/#introduction

If you need professional help in any of this, I also do consulting and/or can do mentoring on my knowledge in this area.

PS: My background is also as a computer programmer with previously zero music making experience. My first tracks were absolute garbage, and that's fine. Every new track is 0.01% better (read: less worse :') than the last one, and that's it. Rinse. Repeat.

Start by starting! Pick a DAW, if you can't pick one, pick one of the most famous. Ableton Live maybe?

Just put some notes down and hit the play button. That's the whole feedback loop. Everything else is just honing your skill and repeating this feedback loop 80 thousand times until you start getting stuff out that you semi-like :)

This. If you are running your agent loop, MCP does nothing.

MCP is an inter-process (or inter-system) communication standard, and it's extremely successful at that. But some people try to shoehorn it into a single system where it makes for a cumbersome fit, like having your service talk to itself via MCP as a subprocess just for the sake of "hey, we have MCP".

If you own your loop AND your business logic lives in the same codebase/process as your agent loop, you don't need MCP at all, period. Just use a good agent framework like PydanticAI, define your tools (and have your framework forward your docstrings/arguments into the context) and you're golden!

My time to shine! I'm a computer programmer but I've been making music digitally for about 15 years now

The software you want is called a DAW - Digital Audio Workstation. There are 300 DAWs, you need to find the one that fits your 'style' or 'workflow'. There are a multitude of paradigms, as making music is not a single technique.

Once you find your DAW, my recommendation is to just make lots of music. Make the music you imagine in your head. Make the tracks that don't exist but you wish they did. Your first 100-200-300 tracks will all be extremely crappy in hindsight, but when you finish them you'll think they are, at the time, a magnum opus each. Keep iterating that process over and over and after many years, you'll start making something that you'll feel semi-proud enough to be able to show your friends!

This is a track I've done 11 years ago:

https://www.youtube.com/watch?v=AlkoEI4Sq7w&list=PL2xsoYcYFo...

and this is a newer track, released "only" 8 years ago:

https://soundcloud.com/flipbit03/twothousandseventeen-feat-m...

so you can definitely notice the difference of what 3 years of music making look like in terms of progress

GOOD LUCK!

I found that design decision a bit odd as well, as the author states multiple times that he's interested in cycle-accurate emulation. When people go for a cycle-accurate emulator, they are purposely eschewing performance for accuracy. e.g. the Higan emulator which focuses on accuracy/code readability, but it's one of the slowest SNES cores out there (and it's fine)