can you share more on the tmux model vs boo?

Tmux is n clients to 1 server.

Screen is 1 server to 1 client.

In screen each client session is a fork of the screen server. In tmux there's one server and many client forks iirc.

this is incorrect. you can have multiple clients using screen -x instead of screen -a

I didn't say you couldn't have multiple clients, I said clients and servers are the same process forked. Or did someone add distinct client/server support to screen finally? I know theres a lot of stuff bolted onto screen over the years but I wasn't aware they dropped forked servers for the tmux model...

Did a bit of digging; the first client gets forked to create the "server". The forked server then detaches and runs in the background. You're right that -x creates an entirely new, separate client process, unrelated to the OG client or the forked server.

Without -x though it works as originally described.

Edit: gnu screen 1.0 was originally released in 1987. The -x flag was released in screen 3.0 in the 90s. TIL

I want boo to be a screen replacement, not a tmux replacement. tmux gives you a whole workspace: layout, scrollback, copy mode, a status bar. screen's appeal was that it did almost none of that: sessions, a prefix key, done. boo keeps that model and swaps the emulation for libghostty so reattach actually redraws correctly.

They also compose: a boo session is just a PTY running a program, so you can run tmux inside one if you want.

Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.

Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) are getting classified that way.

Apologies, half of this indeed was. As I was iterating on the README this seemed apt, but I will refrain!

Appreciated! The community feels strongly about this.

so different projects can have different version, even if they live in the same monorepo?

Really like the theme of the published HTML! Did you take inspiration from any open-source theme?

Out of curiosity, has your org ever evaluated a monorepo approach?

Would be interesting to know what issues you faced considering monorepo and what pushed to have multiple repos.

I think it was just natural approach while using Github

IIUC, many applications, high-performance computing in particular. Check https://en.wikipedia.org/wiki/Remote_direct_memory_access

Big fan of monorepo approach here.

Still, I have recently hit a major issue with the fact that GIT (and other common version control sw) don't have per-directory ACL.

Has anyone dealt with this issue? Which VCS / configuration have you adopted?

> people are using them for their dev environments [?]

Yes, we use a container for dev environment so that we can share the same env across all the team. If it's decided that we need 1 more tool in our toolbox, the script that generates the container is updated (the script is version controlled in the repo too), the CI/CD generates a new container version, all the devs can now use the same NEW environment.

We actually use the container as image for (remote) virtual machines, so we don't really compose multiple containers.

The container has all the tools (for several languages) that we use as a team.

IDEs and debuggers can connect through ssh.

> post-development workflow do you ever use separate containers for build and test?

We build different flavors of the final packaged application, for example:

- production flavor: uses a minimal, nonroot container base image (see: https://github.com/GoogleContainerTools/distroless)

- debug flavor: includes few extra debug tools inside the container

Mostly payload and Airborne time. Idk what is the current status of Zephyr (google search suggests 26 days?) but Loon balloons were consistently reaching 300 days of airborne time.

Zephyr's latest flight had 64 days airborne:

https://newatlas.com/aircraft/zephyr-8-mission-ends-abruptly...

Unfortunately, it ended with a crash.

Thanks for the link. Pretty impressive mission despite the unfortunate ending! Edit: Did it actually crash? The article says it was “brought down” but that could have still been a glide and regular landing if it lost power.

Hi there, my partner is a UI/UX designer and is looking for new gigs. Email me (see my profile) if you want to be put in contact.

Nice! I like the clean and clear style. I think you are presenting yourself in a great way.