For several models like Kimi and glm they have b300 and performance really good. At launch I got closer to 90-100 tps. Nowadays it’s around 60 tps stable across most models I used (utility models < 120B almost instant)

The worst I saw - multiple parallel agents (opencode & pi-coding agents), with Kimi and glm, almost non stop development during the work day - 15-20% session consumption (I think it’s 2h bucket) max. Never hit the limit.

In contrast, 20$ Claude in the similar mode I consumed after just few hours of work.

Personal performance and achievements are usually secondary.

YMMV

However, through the years I learned:

- yes, forks and in general processes are fast - yes, it saves memory and CPU on low load sites - yes, it’s simple protocol and can be used even in shell

However,

- splitting functions (mimic serverless) as different binaries/scripts creates mess of cross scripts communication - deployment is not that simple - security wise, you need to run manager as root and use unique users for each script or use cgroups (or at least chroot). At that moment the main question is why not use containers asis

Also, compute wise, even huge Go app with hundreds endpoints can fit just few megabytes of RAM - there is no much sense to save so few memory.

At worst - just create single binary and run on demand for different endpoints

One, these platforms often come with proprietary data structures, making it challenging to reuse existing database tables or ensuring data rescue in case the application is discontinued.

Two, the focus on generating revenue sometimes compromises data security. It's hard to guarantee that our data won't be used, even in an aggregated or anonymous form, for purposes we might not consent to, especially when dealing with exceptionally sensitive information.

Additionally, several features are locked behind paywalls, and certain licenses may prohibit the use of the open-source edition for commercial purposes.

Lastly, the abundance of telemetry is a constant headache, requiring vigilant monitoring of each release to disable or block intrusive data collection.

WebForms seems to address these concerns, offering a self-hosted, privacy-centric, and GitOps-friendly solution for HTML forms. It empowers users to control their data, integrate it into automation workflows, and maintain privacy in a world where data security is paramount. And it's Free and Open Source under MPL-2.0.

Comments URL: https://news.ycombinator.com/item?id=37895468

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=35269109

Points: 2

# Comments: 0

I have been working with Go professionally since 2015 and quite often it makes me feel frustrated due to lack of full-stack web frameworks.

I was thinking to do something like your project, but with focus to full SSR/zero-js. Lucky me, you started it first . Maybe be in some things I will prefer different approach, however, your project already released (and it's excellent) while mine only in prototype. After I read the documentation in your project it feels like you really stepped on a lot of minefields. Great job!

One thing is still bothering me though (or maybe I missed it in docs): how is Bud dealing with relative links? Very often JS writers forgetting about the situation when the application could be served under different root locations. Does Bud have helpers to construct relative URLs without relying on user-provided server url? (I made PoC for that - don't use it in production https://github.com/reddec/gin-template-manager/blob/eb09f4e8...)

I met a problem: low-end devices that should host a big number of small pieces of logic. To solve the problem I looked back to the history and found CGI and adapted it to the specific case.

As someone said before here in comments: it's just reinvented "good old technology", but I would like to say that I can't find anything bad in it. Old technology means a number of documentations, it means easy to explain.

Ofcourse there are number of issues caused the technology became outdated, but in some cases (defined in target audience) it acceptable. Even sometimes better than newer solutions.

More of that, if you will look at the modern technology (serverless functions/lambda functions) you probably will find the same ideas but wrapped into modern solutions (containers and cloud).

Following is a general response for similar questions.

I pretty sure it's possible to do the same thing as trusted-cgi by combining several tools: cron + nginx/nginx-unit + some deployment + stats + whatever.

It could be faster, more flexible, but... I am not sure that I will personally want to setup it each time for new boxes. Or write auto-install scripts. I would like to write logic, not make environment.

Benefits trusted-cgi are: low resource usage (very low), easy setup, web UI and focus on including several features in one package.

It's possible to find better solutions for each parts, but I would like hear product that providing complete solution instead of providing "bricks". I am a big fan UNIX way, but sometimes we need an assembled thing, instead of another piece of constructor.