hugodutka

Source code of the mod: https://github.com/chasmlol/SkyCraft

Cloning a template is IO-heavy. You can speed it up further by putting postgres on a ramdisk.

Have you considered https://github.com/containerd/overlaybd? It seems to offer very similar features to blockdiff.

I haven't used claude-task-master before, but based on the README, it looks like it's an AI agent that integrates well with IDEs. In contrast, AgentAPI lets you control other agents - like Claude Code or OpenAI Codex - using HTTP calls instead of typing commands into the terminal. For example, you could use AgentAPI to control Claude Code from a custom frontend, such as a native desktop application.

PyMuPDF, a PDF library for Python.

I think so. I'd normalize the text first: lowercase it and remove all non-alphanumeric characters. E.g for the phrase "What now?" I'd create these trigrams: wha, hat, atn, tno, now.

I used this approach extensively over the past couple of months with GPT-4 and GPT-4o while building https://hotseatai.com. Two things that helped me:

1. Prompt with examples. I included an example image with an example transcription as part of the prompt. This made GPT make fewer mistakes and improved output accuracy.

2. Confidence score. I extracted the embedded text from the PDF and compared the frequency of character triples in the source text and GPT’s output. If there was a significant difference (less than 90% overlap) I would log a warning. This helped detect cases when GPT omitted entire paragraphs of text.

It detects if a message contains the ”Final Answer” substring preceded by a specific emoji. The emoji is there to make the substring relatively unique.

You're right that sections reference each other, and sometimes reference other regulations. By creating the "plan for the junior lawyer", the LLM can reference multiple related sections at the same time. In the second step of the example plan in the post there's a reference to "Articles 8-15", meaning 7 articles that should be analyzed together.

The system is indeed limited in the way that it cannot reference other regulations. We've heard it's a problem from users too.

One of the applications are ZK-Rollups [1] which allow developers to move heavy computation off a blockchain. The blockchain receives the results and only validates proofs that they are valid. This is especially useful on Ethereum because its computational throughput is pretty low.

There's also ZCash [2], which is a cryptocurrency that lets you make untraceable transactions. This is in stark contrast to Bitcoin or Ethereum, where transaction information is available publicly to everyone. They have a series of blog posts [3] on the math that actually makes it work under the hood.

[1] https://ethereum.org/en/developers/docs/scaling/zk-rollups/

[2] https://z.cash

[3] https://electriccoin.co/blog/snark-explain/

This is the WASM blob and it's 1.1 MB uncompressed. https://github.com/rhashimoto/wa-sqlite/blob/master/dist/wa-.... No issues - it's cached by cloudflare.

We're using IndexedDB. Here's a writeup on alternatives https://github.com/rhashimoto/wa-sqlite/issues/85 and a benchmark https://rhashimoto.github.io/wa-sqlite/demo/benchmarks.html

With something called Rich-CRDTs - they were invented by Electric's CTO. They have a section in the docs and some blog posts dedicated to it: https://electric-sql.com/docs/reference/consistency#rich-crd...

There's a workaround - if a table has an "electric_user_id" column then a user with that id (based on their JWT) can only read rows which have the same id. It's basic but it works for us. https://electric-sql.com/docs/reference/roadmap#shapes

We have run into queries that corrupted the database client-side, but fortunately that doesn't propagate into postgres itself. In that case we had to drop the client-side db and resync from a clean state.

The corruption was also caught by sqlite itself - it threw a "malformed disk image" error and stopped responding to any further queries.

Also bugs around syncing some kinds of data - one bug that's already been fixed was that floats without decimal points would not get synced. https://github.com/electric-sql/electric/issues/506

In general electric's team is very responsive and fixes bugs when we bring them up.

Every postgres migration is done through an Electric proxy and it converts it into a corresponding sqlite migration that it can apply later on the client. In case of a migration that would be somehow breaking you can also drop the client-side sqlite database and resync state from postgres.

We've been using https://github.com/electric-sql/electric for real-time sync for the past month or so and it's been great. Rather than make you think about CRDTs explicitly, Electric syncs an in-browser sqlite db (WASM powered) with a central postgres instance. As a developer, you get local-first performance and real-time sync between users. And it's actually faster to ship an application without writing any APIs and just using the database directly. Only downside is Electric is immature and we often run into bugs, but as a startup we're willing to deal with it in exchange for shipping faster.

It looks like HN automatically stripped the reference to the comment I originally linked to: https://github.com/rui314/mold/issues/190#issuecomment-14028.... The title should be more clear in this context.

Oh yes, in this post I was not trying to. Hocus gives you a web interface that lets you spin up a dev env with a single click of a button. We also implemented a git-integrated CI system that prebuilds your dev env on new commits. It’s basically a self-hosted Gitpod or GitHub Codespaces.

Nix solves a different problem than Hocus. Nix lets you define a development environment, Hocus gives you a way to run it on a remote server. Right now we use Dockerfiles to let users define the packages they need in their dev env, but we would like to support Nix in the future too. Interestingly, you can use custom BuildKit syntax https://docs.docker.com/build/dockerfile/frontend/ to build Nix environments with Docker https://github.com/reproducible-containers/buildkit-nix, and that's probably what we will end up supporting.

I didn't want to go into all the technical details, but we have another write-up that goes into details about RAM management: https://github.com/hocus-dev/hocus/blob/main/rfd/0003-worksp...

Other than making sure we release unused memory to the host, we didn't customize QEMU that much. Although we do have a cool layered storage solution - basically a faster alternative to QCOW2 that's also VMM independent. It's called overlaybd, and was created and implemented in Alibaba. That will probably be another blog post. https://github.com/containerd/overlaybd

We do, and we'd love to use it in the future. We've found that it's not ready for prime time yet and it's missing some features. The biggest problem was that it does not support discard operations yet. Here's a short writeup we did about VMMs that we considered: https://github.com/hocus-dev/hocus/blob/main/rfd/0002-worksp...

If you’d rather use a self-hosted alternative, we are building Hocus [0]. It’s still in alpha, but already supports prebuilds, VSCode, shared environment variables, and more.

[0] https://github.com/hocus-dev/hocus

Hocus is more cost-efficient when you need larger instances. If you need 8 CPU cores ($0.72/hour on Codespaces) and a single dev uses their IDE for 4 hours a day on average, Codespaces itself would come out to about $0.72 * 4 * 5 * 4 * 30 = $1728 a month. But that gives me the idea that maybe we should introduce cheaper pricing plans but with limits on VM resources - pay less if you have lower compute requirements.

Thanks, this looks useful. We will consider using keygen in the future.

We definitely want to optimize Hocus for large repos. We have some ideas how to reduce disk usage by stacking qcow2 files, but we haven't settled on anything specific yet. Thanks for the link!

We made these custom deployment scripts to walk the user through the installation process and make it more organized. We could just use plain docker compose but then we would have less control over what we show to the user - things like helpful error messages. For example we detect if you have KVM support enabled and if not, we suggest you should enable it in BIOS. Under the hood these scripts are just wrappers for docker compose with guardrails.

By multi-node support we mean the ability of Hocus to manage multiple machines, so you can run dev envs on more than one server and handle more concurrent users. These environments would not communicate with one another. From the end user's perspective using a multi-node deployment vs a single-node deployment would not differ. If you needed 2 distinct environments I would suggest using virtualization within a single dev env.

Thanks! The pricing is there mostly to set expectations for the future. The current release works (for the most part) for individual users and it would not support a team well. Hocus is free for up to 3 users, so we expect people who deploy the alpha version not to pay a thing.

> what happens if I want to check out a 1 year old commit and edit it?

Your dev environment is version controlled too because it lives in your repository. You would run a prebuild for that old commit and get a dev env from that time. It would only break if your old dev env can no longer be built, for example if it depended on some external resource which is no longer available on the internet.

> I'd rather see something on a (calendar) schedule with the potential to trigger a manual build if needed.

That's actually on our todo list, but it didn't make it into the 0.1 release. This feature is especially useful for monorepos, where rebuilding everything on every commit is too much.

That's something we would love to do in the future. For now extending the base development template so that it has the most popular programming languages already installed is on top of our todo list.