1) Ollama, Pro, Single account. Will not trust my serious work to Big Tech.
2) Tried some local models. Need bigger GPU for that though. On Ollama, I'm super happy with (cloud-hosted) DeepSeek 4.1 Flash and GLM 4.3 Flash , which almost don't burn any tokens at all(!), until I can buy a better GPU.
3) OpenCode, running in the official Ollama Docker image.
4) Exploring https://epiq.sh which is a local TUI issue board optimized for agents
1. LLM usage, in particular unsupervised, tends to build up "cognitive debt"
2. It tries to characterize the concept, including to propose a score for it
3. Notes that the level at which one can let the agents loose (and allow some CD) differs quite a lot between core business domains and more peripheral ones
I switched to ProcessWire [1] a couple of years ago, and haven't been happier.
It succeeded to do what Drupal tried but never managed to do:
It is both extremely stable and extremely flexible at the same time.
By having an extremely generic and small core, combined with an extremely powerful programmatic API (basically jquery for data from the CMS, but better), you don't need fiftyeleven modules to achieve some basic tasks.
Thanks for sharing! I would love for some go to source for this type of insider info from the people who actually have tried. (The best I've found so far are some guys on Twitter/X like Alex Fateev (https://x.com/superalesha) and AJ (https://x.com/ItsmeAjayKV))
I'm personally sitting on an extremely limited Geforce GTX 1660 6GB, and would like to see how far one could go even with such a crappy card.
At least it was quite amazing to see the difference between CPU-based and even this crappy GPU-based inference when trying out some tiny models in jan.ai. It's still like orders of magnitude faster at least.
Try to use your IGPU as well if you have enough RAM, almost everyone has dual GPUs in their computers.
Use Vulkan build of llama.cpp to run low parameter MoE models in your IGPU and CUDA llama.cpp to run dense models in your DGPU.
Ofcourse you need to set your expectations right on what problem you want to solve, I've not been happy with using quantized models for coding even on a decent laptop; where as for NLP, ASR, STT etc. work great with this setup.
I like that the code example seems to indicate they took the concept of "ports" from flow-based programming, which might be one of it's absolute strongest points:
That is, enabling data flow connections between individual inputs/outputs, and not just between components, which otherwise is too limiting, and typically causes a lot of extra syntax to handle that routing otherwise.
That aside: really cool article! Dataflow just pops up everywhere as a really, really useful abstraction, and our languages don't support it well as a general mechanism.
Instead we tend to have specialized dataflow-y tooling for one area of programming where the advantages are so significant that the impedance mismatch is worth it nonetheless.
I think you are right, and I should have done a search on that before. Found now that FBP inventor cites someone Weinberg from 1975 about them (though FBP is supposed to be from around 69-70, so might be a somewhat parallel discovery):
> Now what are "IN" and "OUT" that our pseudocode receives IPs from and sends them to? They are not the names of connections, as this would tie a component's code to one place in the network, but are things called "ports". "Portae" means "gates" in Latin, and ports (like seaports) can be thought of as specific places in a wall or boundary where things or people go in or out. Weinberg (1975) describes a port as
"... a special place on the boundary through which input and output flow... Only within the location of the port can the dangerous processes of input and output take place, and by so localizing these processes, special mechanisms may be brought to bear on the special problems of input and output."
Still, I'm amazed at how it took so long before they became mainstream in data flow oriented libraries and DSLs.
And it seems J.P. Morrison was also highlighting Named ports as particularly useful, which is also perhaps what I should have highlighted in my initial comment above.
It's gotten better lately it seems, but a lot of tools skipped that part, which now requires tons of specialized syntax just for routing of multiple parallel streams.
I'm not trying to be pedantic, but they're different words, and (esp. considering how capable our community is when it comes to logic and precision with programming languages) I find it strange how often this "it's / its" error is repeated. Calling it out in hopes of helping others get it right.
There's nothing strange about how often this error is repeated. It is a fault in the "design" of the English language, which violates its own rules, insofar as it has any. Apostrophes are used for both possessives and contractions, eg. "That's John's ball". Indeed possessive "it's" was historically written with the apostrophe. That the apostrophe was dropped to become possessive "its" is completely arbitrary special-case logic, and given that there is no logic behind which it was dropped from, it is easily subject to confusion because you cannot reason about which is which if you forget in the moment.
I really don't think it's an issue with how the language is structured. I think it's more an issue of posters using mobile devices and not spending a lot of time copyediting their comments. It surprises me how many users on here shamelessly post mobile-subdomain links, rather than the desktop ones that only redirect to mobile if you're on a phone.
Thanks for your response. You raise an interesting point, but I take a different view. Contractions _always_ use an apostrophe, while possessives only sometimes do [they're / their, you're / your, he's / his, she's / her, it's / its, ...]. For "it", the apostrophe alone serves to distinguish between the two words.
Are you really gonna say that? Are you sure you don't wanna reconsider? That's kinda sorta not true, I've gotta say, especially what with Halloween coming up soon.
> For "it", the apostrophe alone serves to distinguish between the two words.
Sure, but that doesn't establish which to drop it from. English coulda just as well dropped it from the contraction.
was this discussion not about apostrophes? but yes, different sets of pronouns work differently. more to the point, those different ways are not confusingly akin to contractions.
Indeed nothing. Of course the English language is rife with logical inconsistencies; you're attempting to double down on a strawman argument.
Reread my comment and you may notice that "logic and precision" referred to capabilities of the people in the HN community, not characteristics of the English language. Of course (as demonstrated in this very thread), that capability is not evenly distributed.
Yea, I think I kind of know this in theory, but tend to mix them up sometimes as a non-native English speaker. Good to try to iron out those common mistakes though for sure.
Looks like a really cool project, especially for quick no-setup use cases.
If you prefer to keep things local and open source, and your agents' notes do fit in issues, you might want to check out Epiq too, which is a local but distributable issue board synced via an event log mechanism to ensure consistency when syncing across repos:
2) Tried some local models. Need bigger GPU for that though. On Ollama, I'm super happy with (cloud-hosted) DeepSeek 4.1 Flash and GLM 4.3 Flash , which almost don't burn any tokens at all(!), until I can buy a better GPU.
3) OpenCode, running in the official Ollama Docker image.
4) Exploring https://epiq.sh which is a local TUI issue board optimized for agents
5) Nope.
reply