Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Superlogical

superlogical.com

Post reply on HN
Print view View original

421–430 of 504 posts

Re: Superlogical

#421

Post by samuell »

brandall10 wrote: post #120

This sounds like a mashup of of several things I've been playing with lately... - pi-web ( https://pi-web.dev/ ): a web frontend for the Pi coding harness which can multiplex pi sessions across multiple machines - herdr ( https://herdr.dev/ ): a fairly polished agentic multiplexer TUI, can easily spawn or destroy windows based on subagent activity - firstmate ( https://github.com/kunchenguid/firstmate ): a meta envir…

Pardon the plug, but I thought I'd point out that I think SciCommander [1], or the ideas behind it, could be very relevant for this stack.

It does capture a provenance graph for any ad-hoc shell commands executed in the shell mode, or if prepended by `sci run`, by tracing all new files created from commands, and creating an accompanying json file for every output with metadata, which can later be assembled into a graph specific to any output file, using the `sci tohtml` or `sci toshell` commands (producing an HTML report with an SVG graph, or a reproducing shell script, respecively).

I'm quite bullish of the possibilities with this approach.

And, this was in fact also born out of the thinking to "rip apart" workflow tools, and build them up again using small, well-defined tools that do one thing well.

[1] https://github.com/samuell/scicommander

Re: Superlogical

#422

Post by lordgrenville »

CamperBob2 wrote: post #398
darkwater wrote: post #395

Earlier quoted context omitted.

With tux the biggest difference and gain is that you can detach and resume the terminal session, leaving processes running on the "server" (where tmux was initially started) even if your "client" disconnects. On top of this, you can have multiple terminals inside the same session.

So it's like launching processes with nohup?

Yes, except if you launch a process with nohup, then close your terminal and open a new one how do you reconnect to it? I assume there's a way to do it but I don't know how (probably someone with more unix-fu will reply), plus you can't see the previous output. Whereas with screen/tmux you can just pop it open again and see the whole session.

Re: Superlogical

#423

Post by backscratches »

rasmus1610 wrote: post #407
Hissigh wrote: post #396

Earlier quoted context omitted.

I don't really get it either. I installed it to try it out, but I still don't understand why it's getting so much attention. I don't even use tmux. My window manager already gives me workspaces, splits, and tiling, so I don't need those features there. I also prefer focusing on a single project instead of juggling five at once. And I don't really care about notifications. I just switch back to the relevant workspace…

you miss the multiplexer part. multiplexers are awesome if you have them on a persistent machine like a server you SSH into. To me herdr feels more like a modern alternative to tmux or zellij with the agent features being a nice add on.

Isnt zellij quite modern? What does herdr do better than zellij?

Re: Superlogical

#424

Post by ButlerianJihad »

CamperBob2 wrote: post #398
darkwater wrote: post #395

Earlier quoted context omitted.

With tux the biggest difference and gain is that you can detach and resume the terminal session, leaving processes running on the "server" (where tmux was initially started) even if your "client" disconnects. On top of this, you can have multiple terminals inside the same session.

So it's like launching processes with nohup?

By default, SIGHUP has no signal handler, and so a process that receives it will exit. The kernel should send SIGHUP to all child processes when you quit the shell session or the terminal file (pty/tty) is closed. Processes trying to write to a nonexistent terminal may be terminated by SIGPIPE.

So you launch a process with nohup(1). This puts SIGHUP and others on ignore status, redirects output to a file, and then executes your process. This is similar to how a daemon starts, when it explicitly dissociates from any terminal device.

With tmux or screen, a layer of pseudo-ttys (ptys) is created, and process groups are managed, so your terminal's pty is only connected to the master tmux process, and each subprocess/window is assigned a new pty and process group of its own, as if you had remotely logged in to each shell.

So tmux is now handling SIGHUP and can detect when your terminal or session closes out. The persistence of subprocesses comes from the fact that they aren't receiving SIGHUP and that they are still associated with pty, as tmux is running "daemonized" until you reattach.

Re: Superlogical

#425

Post by backscratches »

CamperBob2 wrote: post #366
aprdm wrote: post #356

Earlier quoted context omitted.

If you're using Windows you're likely not the audience. Which is fine.

Not really; not without understanding what am I missing. Why does Linux need a "multiplexer for all work," while Windows either already has one, doesn't need one, or couldn't use one?

A Multiplexer let's you run multiple terminals in one window, this is a new one. WindowsOS does not get as nice of tools as Linux generally.

Re: Superlogical

#426

Post by jagadaga »

Sorry, the text is too vague - what are they building exactly, another tmux?

P.S. That custom disappearing scrollbar doesn't look super logical; it doesn't even look logical, tbh.

Re: Superlogical

#428

Post by [deleted] »

brandall10 wrote: post #120

This sounds like a mashup of of several things I've been playing with lately... - pi-web ( https://pi-web.dev/ ): a web frontend for the Pi coding harness which can multiplex pi sessions across multiple machines - herdr ( https://herdr.dev/ ): a fairly polished agentic multiplexer TUI, can easily spawn or destroy windows based on subagent activity - firstmate ( https://github.com/kunchenguid/firstmate ): a meta envir…

[deleted]

Re: Superlogical

#429

Post by dregitsky »

brandall10 wrote: post #120

This sounds like a mashup of of several things I've been playing with lately... - pi-web ( https://pi-web.dev/ ): a web frontend for the Pi coding harness which can multiplex pi sessions across multiple machines - herdr ( https://herdr.dev/ ): a fairly polished agentic multiplexer TUI, can easily spawn or destroy windows based on subagent activity - firstmate ( https://github.com/kunchenguid/firstmate ): a meta envir…

These tools all assume you have machines to run the agents on. But for parallel agents I'm pretty convinced you want each agent on its own isolated devbox running your dev environment (not e.g. worktrees on one box) - which isn't trivial to set up and manage.

I'm working this with https://boxes.dev - a workspace for launching and managing claude + codex sessions, each running in its own cloud devbox.

We launched with a desktop app but have gotten a lot of pull for terminal-driven workflows, so have a TUI as well. It's interesting - when the Codex desktop app launched I was so sure that GUI is the future for coding agents (it's just a chat!). But turns out there's no killing the CLI

Re: Superlogical

#430

Post by 63stack »

jagadaga wrote: post #426

Sorry, the text is too vague - what are they building exactly, another tmux? P.S. That custom disappearing scrollbar doesn't look super logical; it doesn't even look logical, tbh.

Yes. I find it quite funny that 4 people with the flashiest of titles (head of experience?) came up with this amazing plan:

1. it will be incredible

2. it will be composable

3. it will be safe to use in production

I would totally invest millions into these guys, they have a bright future ahead.

Post reply on HN