I'm a bit curious why not running DeepSeek V4 on top of https://github.com/antirez/ds4. I think the results could be really good.
HN user
c4pt0r
Rust/Go
Local open weight models will definitely be a future trend. Imagine if an Opus-level model could run locally: many more latent use cases would likely emerge, since Opus is priced so high. Perhaps the future will be a multi-model architecture, where frontier models handle planning and local models carry out the concrete execution.
Hi HN, Pie author here
I’ve been building pie, an open-source coding agent written in Rust. The initial reason was that I had some proactive, long-term automated tasks to run on a local DS v4 model. Therefore, I needed a customizable agent runtime to support these custom tasks, such as triggers, to perform some simple automation, Over time, the project gradually became more and more usable, so I thought I might as well turn it into a proper project. Of course, most of the code in this project was written by AI. If you’re sensitive to AI-generated code or AI coding, feel free to simply ignore it.
Pie runs inside your local project directory, can inspect/edit files, run shell commands, keep resumable sessions, and use different model providers, including local OpenAI-compatible servers.
The goal is not just to build another chat UI for coding, but a local agent runtime for developer workflows: slash commands, session history, skills, MCP tools, cron/triggers, and a small hub so agents running on different machines can send messages to each other.
A few things I’ve been focusing on recently:
- local/session-first workflows: resume sessions, search history, save transcripts
- model flexibility: Anthropic/OpenAI/etc., plus local OpenAI-compatible endpoints
- MCP and skills for attaching project-specific tools/instructions
- cron/triggers for lightweight automation inside a coding session
- SSH/headless support for running agents on remote dev boxes
- a web UI that mirrors the terminal runtime rather than replacing it
- an optional hub for agent-to-agent messaging and notifications
Love to hear feedback from you, thank you!
i know they will have alsamixer in this list.
it has nothing to do with TiDB, db9 is built from scratch.A good way to think about it is that db9 is similar to tidb-server, it provides a PostgreSQL wire protocol and SQL layer, while the actual data lives in the underlying KV layer.
yes, it’s quite a journey
Hello, the developer of db9 here. You’re right, that section is indeed a bit too brief. We will add more architecture documentation later. What I wanted to convey is that, unlike a standard PostgreSQL, db9 is more like a pg SQL-compatible layer built on top of a large distributed KV store. I also shared a brief introduction in this tweet, which might help clarify things. https://x.com/dxhuang/status/2032016443114733744
IMHO, sometimes strangers can offer advice without bias, whereas those closest to you cannot.
In large-scale metadata scenarios, JFS recommends using a distributed key-value store to host metadata, such as TiKV or FoundationDB. Based on my experience with large JFS users, most of them choose TiKV.
Disclaimer: I'm the co-founder of TiKV.
https://0xffff.me some random stuff
https://me.0xffff.me blog
well...Many database vendors offers free databases for dev purpose for years, i mean it's not a news.
Paired with programming tools like Claude Code, it could be a low-cost/open-source replacement for Sonnet
Maybe a bit off-topic, but the minimalist style of the blog looks really cool.
I'm curious if it matters if it's sqlite since it's already a serverless product
- Yes, the storage is distributed kv.
- Yes, it's SQL on distributed transactional kv
- SQL layer is stateless, runs in multiple containers
- SQL layer would push down compute logic down to the storage(like, filter/predicate)
....Yes, that reminds me of TiDB
TiDB Serverless is built on S3, it's in production for more than 2 years, Blog link: https://me.0xffff.me/dbaas2.html
Very handy!
A good example is TiDB's implementation of vector indexes. TIDB is also a MySQL-compatible distributed transactional database, which separates the storage engine for vector indexes from the transactional store through an extra replica in its OLAP engine (via TiFlash), avoiding resource contention.
TiDB
TiDB CTO here, I think that a clear boundary between components is beneficial for the maintainability of a distributed systems like TiDB, and automated deployment tools like `tiup`(https://tiup.io) and the Operator of Kubernetes shield end-users from this complexity in order to maintain best practices in deployment. While still providing enough debugging details for advanced users.
I can imagine a single uncaught exception bringing down the entire payment system...
Really glad to see Qwen2 uses Apache 2.0 License.
Not really wanting to comment on the use of this program (it's useful), but just from the quality of the code, it's very good!
Seems like a good Swiss Army Knife-like addition to the shell script (reminds me of awk as well). It would be interesting to keep it that simple (not another Perl)
For MySQL users today, there are modern cloud-native replacement solutions, such as tidb(tidbcloud.com), where tidb (github.com/pingcap/tidb) provides a MySQL-compatible syntax layer but it's not MySQL.
Interests: I work at TiDB
As a firefox user it hurts to see this news, wait, isn't mozilla a non-profit organization?
I think a lot of shared-nothing systems are similar from high level, connection handling / storage node (with small shards) / Metadata (routing)
https://www.notion.so/Some-notes-on-DynamoDB-2022-72a2a1f225... I also put a copy on notion, in case the link doesn't work.
CTO of TiDB here. TLDR, yes, DBA is still a good job, but to embrace new technologies.
From a database developer's point of view, I have always admired the work of DBA, although I can develop the kernel of the database, I can also write a SQL engine, never been good at writing complex and efficient SQL, totally different skills.
I have noticed a trend in the database field in recent years: Everything goes to the cloud.
Because of cloud is more and more popular, and the cloud is providing fully managed database service, it is hard to say the trend of traditional DBA job is getting less and less, the DBA expert is still extremely popular, However DBA will alive and can be more welcome, because there are more and more new technologies are evolving fast, just like what we're proudly building: TiDB, an HTAP database provides SQL interface, support complex analytic workloads, as well as the OLTP load. DBA could reuse their skills, and even better, they are not just DBA, they can also act as a data expert, help application developers to optimize SQL queries, and schema design, and help them to design and optimize systems.
A good example is my recent little side project: https://ossinsight.io/, although the architecture is simple, it contains some complex SQL in there, I turned to my DBA friends to get this application done correctly and efficiently.