reddec

granite 4

Second here. From recent Alibaba Qwen conference: the all-in-one box (DC in a box - I think I was called Apsara, 0.6x0.6x1.5m) plug and play, 1.5TB GPU RAM, capability to run in a fully air gapped environment, any open models... All of that is roughly $300k one time. And this box can do non LLM tasks as well. Performance (throughput) around 20k t/s. Delivery time - around 2 months. For any medium sized company its perhaps cheaper to just buy it once than spending 1.5k for cloud per user

I have roughly 20-40M token usage per day for GLM only (more if count other models). Using API pricing from OR it means ollama more profitable for me after day (few days if count cache properly).

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)

Background agents (diy OpenClaw like), coding, assistant (openwebui).

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.

My 50c - ollama cloud 20$. GLM5 and kimi are really competitive models, Ollama usage limits insane high, no limits where to use (has normal APIs), privacy and no logging

In my experience, promotion depends on: (a) is cheaper (including on boarding) to fire and hire or pay more, (b) will it cause domino effect so others will also ask for promotions, (c) will employee find an offer outside (matter of personal traits and market conditions).

Personal performance and achievements are usually secondary.

YMMV

I tried BIND, Dnsmasq, unbound, adguard. At the end I picked CoreDNS outside kubernetes. It can do everything (including wildcards and ACL), requires few resources and easy to configure.

Few years ago I felt the same and created trusted-cgi.

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

Luckily Bitwarden supports passkeys. And you can self host it. And even vaultwarden/bitwarden-rs supports passkeys

Nice. Once upon a time we created something like this. https://github.com/reddec/oidc-login (Client only)

This project emerged from a crucial need to store highly sensitive information while maintaining the flexibility to integrate with various automation solutions. I've explored options like Baserow, ApiTable, and many others, but they all raised significant concerns for me.

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.

Did you try POST (regardless of docs)?

I felt exactly the same as the author. That's why I created https://trusted-cgi.reddec.net/ (currently on the way to v1 and under the heavy refactoring)

Tiny wrapper built around standard Go SQL library and SQLx with Go 1.18 generics support.

From my point of view, SPA is really good when you need to use one API for different kinds of clients: web, mobile apps, cli etc. Second benefit is predicted relative routing: in case you're serving your web app (with hash router) as one page, you may don't worry about subpaths (ex: page served as /webapp will work properly under /foo/bar)

First of all - great work, thanks. Will follow the progress.

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...)

Looks nice. I did something similar not so much time ago https://github.com/reddec/git-pipe

I have been working on wrapper around Tinc to simplify setup. Project: https://github.com/reddec/tinc-boot Article: https://dev.to/reddec/tinc-boot-full-mesh-vpn-without-pain-3...

To be fair I am not trying to say that CGI is a bleeding edge technology)

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).

Interesting. Could be useful for high-load, however for quick setup feels like a little bit complicated. Are any known UI, or scheduler settings?

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.

Thanks for tip: several ideas from there look very promising

I hope, I fixed it

Right. Trusted-cgi also adds security checks (with various checks), "actions", scheduler and web UI =)

I would like to suggest to stop measure benefits of both projects and just "steal" them from each other, making end-user experience better for both projects ;-)

Great project! However, I think our projects similar but not the same. Looks like we can exchange some ideas from each-other

Heavy, very heavy. Even with k3s. I tried it first. Even plain k3s will run slowly on 1GB machine (a target audience)

Any script/application that can parse STDIN and write something to STDOUT is capable for the project.

Hobby projects or projects with low number of requests are ideally fits. And it could be run on very low-end devices: raspberr pi, cheapest VPS, etc..

Exactly! Just adapted for a new reality. And I found it quite exciting to adapt old proven technology to a new stack

The point is to use low-end machines for a number of logic that 99% will do nothing. As example: webhooks. In this scenario there is no need for high performance/low latency but there is a high demand of low resource usage. However there's a way to scale it horizontally using shared storage. But it should out of scope.

Btw I am author of it and I will be happy to answer on any questions. Thanks for your interest!

Demo https://reddec.net/demo/github-card/

Check online demo https://reddec.net/demo/element-logo-generator/