Huh, somehow I had no idea that Obsidian wasn't open source. I guess I was fooled by the open source plugins.

Claude Code (subscription) has Agent Teams built in. Teams of Agents communicate with local files that they use as inboxes and task list. Has tmux and iTerm 2 integration. https://code.claude.com/docs/en/agent-teams

They can rack up some extra tokens if you leave agents going idle. Because they loop, checking for new messages for them.

This fellow reverse-engineered exactly how it works and then abstracted the pattern into an MCP server that any Harness/agent can use. https://github.com/cs50victor/claude-code-teams-mcp

People always warn that this setup can corrupt your stuff, which I understand you definitely wouldn't want to try to share Git via Google Drive.

Obsidian shows a warning about this. But the only issue it's pointing out is that mixing Obsidian's built-in sync with something that syncs your files is likely to cause problems. Otherwise it's a perfectly safe and normal way to sync.

Given that it's paywall, there's a good reason for that. (gift link below no longer works)

Posts with links to paywalled articles should be identified somehow. (Flashing red title??)

I would prefer to just skip them, but they are not easy to spot.

Using Claude Channels can make it easy to inject prompts and get just the response back without having to identify it in the terminal output or fight with the TUI.

But they're not well designed, and some things just have to go in through the terminal interface like slash commands (i.e. `/clear`)

The law of Software Envelopment. Jamie Zawinski in 1995 stated that "software inevitably expands to include email functionality, or it is replaced by software that does"

Clearly, that's not the case anymore. Nowadays you just swap out "email" for "LLM"

Oh my gosh, he's trying to stay awake but having a hard time so he keeps tiping over.

As software engineers, I get the feeling we’re moving almost entirely away from code.

> As software engineers, I get the feeling we’re moving almost entirely away from code.

Wille-Driven Development — I prefer the word from Schopenhauer's Die Welt als Wille und Vorstellung (The World as Will and Representation).

What we will begins to matter more. The gap between desire and existence is collapsing. In Genesis, creation is a pure speech-act: fiat lux, and it was so — no implementation details, no build step, will and result simultaneous. We're not there yet. But I find the distance is measurable and shrinking.

The Representation — code, syntax, toolchains — is receding. The Will asserts itself more directly. Welcome to the future.

Nice! I'll read up on it.

The backwards horse is my fault, period. I didn't read the direction.

1. Start with root to bind the port below 1024.

2. give up root because you don't need it any further.

3. Only accept non-root logins

4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

That still needs a way to change users, and OpenSSH already has privilege separation. That hardens the process somewhat to reduce the amount of code running in the process which can change the uid for a session but fundamentally something needs permission to call setuid() or the equivalent.

Yes, but changing users is a function of the shell (or maybe more specifically /usr/bin/login), not the SSH daemon.

Yea, but then we’ve recreated this CVE which is caused by calling login(1) unsafely. The point was that the person I was replying to misunderstood the problem and largely seemed to be conflating telnetd with OpenSSH.

Congratulations, you've created a server that lets people have shells running as the user running telnetd.

You presumably want them to run as any (non root) user. The capability you need for that, to impersonate arbitrary (non-root) users on the system, is pretty damn close to being root.

Well obviously each user just needs to run their own telnet daemon, on their own port of course.

You still need to have privileges to become the userid of the user logging in. Openssh does do privsep, but you still need a privileged daemon.

I'm not sure that you need root because of the port - I think login itself needs to run as root, otherwise it cant login to anything other than the account its running under.