Live data from Hacker News

Pi's Minimalism Is Its Advantage

earendil.com

301–307 of 307 posts

Re: Pi's Minimalism Is Its Advantage

#301

Earlier quoted context omitted.

The claims being made here are fallacious in three extremely basic ways. First, "I regularly have 10+ instances of my harness running or idling on my laptop" implicitly asserts that you need that many instances running at once. You don't. You can have a single instance running that handles your sessions in parallel. Second, "I sometimes run my harness on machines that are low-power, low-RAM single-board computers." p…

This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop. > that can run their tool calls in a separate process/host That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop? > You can ha…

> This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.

You're very much operating based on emotion rather than reason. That's fine in general, but it's not OK for HN, which is not a place to blast out your emotions and try to assert that your opinion is factually true by getting maximally angry about it.

> That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?

You don't understand how harnesses work. Let me explain: in a harness, the tools that the harness provides are the only way for the agent to interact with its environment, and as such, if the harness is run on one host, and the tools on another, the agent's perspective is that it is running on the second host. This is effectively true modulo some small set of scenarios that are mostly irrelevant in the case of "I'm SSHing into an SBC" (e.g. the harness logic and LLM API calls would both be happening on the SBC, which you definitely don't want when you're resource-constrained).

> Sounds even more elegant! Presumably, they communicate via HTTP?

No. Why would you think that? Again, I don't think you understand how harnesses work.

> I don’t need to, but I can. That’s the entire point, in case you’re still missing it.

That's a useless point, if so, akin to saying "I want to have Vim running at address 0x00000001beef0000 in physical memory" - you're conflating use-case (needing a large number of agents running in parallel so you can work on things in parallel) with implementation detail (having a large number of separate processes running on your computer).

> How beautifully ironic.

I'm meeting every single one of your technical arguments and factual inaccuracies (e.g. your misunderstanding of the word "contrarian"), and you're continuing to get very angry at Javascript. I don't think there's any irony here.

Re: Pi's Minimalism Is Its Advantage

#302

Earlier quoted context omitted.

I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.

it's certainly easier to keep a single directory under version control and share between Linux and macOS

Yeah but what happens when it's a mix of config and local state like logs and the app database?

Re: Pi's Minimalism Is Its Advantage

#303
post #214

Earlier quoted context omitted.

I can't offer a definitive list. But some/all of web access, web search, sub-agents, plan, goals, looping, and maybe a to-do list. I'd suggest the default should be anything that makes the model more efficient or effective to a reasonable current level.

Are you sure those tools make the model more efficient?

No.

But:

web access, web search --> basically essential at this point

plan, goals, looping --> necessary if this is how you work, and working like this is probably (arguably?) more efficient

to-do list --> IME seems to help efficiency with local agents if they utilise it, but this is totally subjective

sub-agents --> who knows

Re: Pi's Minimalism Is Its Advantage

#304

Lots of praise for Pi in this thread, so I'll offer up a diverging opinion. Given all the hype, I was a bit underwhelmed by Pi. It definitely has some good ideas around customization, but it annoyed me in many little ways. For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME d…

> I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.

Have you looked at Crush (https://github.com/charmbracelet/crush)?

Written in Go, compiled binary, respects XDG (e.g. uses ~/.config/crush to store config), etc. No Lua scripting, but it includes a skill to manage its own configuration.

Re: Pi's Minimalism Is Its Advantage

#305

Earlier quoted context omitted.

> Nobody is inconvenienced by a 3.5s startup time of an application meant to run for hours or days. For the record, I measure acceptable latency in milliseconds. I think it has something to do with my brain. > which is literally admitting to being reflexively contrarian. They’re very clearly stating that they’re expressing their opinion because it is underrepresented. > Did you forget to make a point here? No.

> For the record, I measure acceptable latency in milliseconds. I think it has something to do with my brain. That's a personal preference thing. You're not really being inconvenienced. > They’re very clearly stating that they’re expressing their opinion because it is underrepresented. That's literally the dictionary definition of being contrarian: "A person who likes or tends to express a contradicting viewpoint, es…

> you probably shouldn't be on HN. HN is for intellectual curiosity and debate, not Reddit-esque expressions of randomness conflated wuth humor.

Thank you for this beautiful insight. Just to clarify, you consider yourself an intellectually curious, HN-worthy individual?

Re: Pi's Minimalism Is Its Advantage

#306

Earlier quoted context omitted.

it's certainly easier to keep a single directory under version control and share between Linux and macOS

Yeah but what happens when it's a mix of config and local state like logs and the app database?

Looking around my own cluttered home folder, the pattern seems to be that applications will split their "singlefolder" into a subtree.

For example:

- .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var

- .gitkraken has: logs, notif, profiles, repohooks, service, themes

- .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad

- .dropbox has: events, instance1, instance_db, logs, machine_storage, metrics, ssa_events

- .steam has: bin, bin32, bin64, debian-installation, root, sdk32, sdk64, steam

- .xpipe has: cache, logs, settings, shell, storage, webview

...etc

I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.

Re: Pi's Minimalism Is Its Advantage

#307

Earlier quoted context omitted.

Yeah but what happens when it's a mix of config and local state like logs and the app database?

Looking around my own cluttered home folder, the pattern seems to be that applications will split their "singlefolder" into a subtree. For example: - .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var - .gitkraken has: logs, notif, profiles, repohooks, service, themes - .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad - .dropbox has: events, instance1, instance_db, logs, machine…

Totally valid, and the Unix-style filesystem sprawl is definitely a pain sometimes. On the other hand, when an application does follow standards, you always know where something is, and just by looking at the name of the directory you know what's in there.

The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever.

It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc...

I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.

Post reply on HN