jabr · HackerTrans

3 months agodiscuss

You’ve been able to do download/upload progress using the Streams API with fetch for more than seven years now. https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

jabr

7 months agodiscuss

State replication is currently based on corrosion: https://github.com/superfly/corrosion

jabr

7 months agodiscuss

> In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer

In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe.

In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.

jabr

7 months agodiscuss

I haven't tried it, but EPMD with DNS discovery should work just fine, and should be similar to this NATS example: https://github.com/psviderski/uncloud-recipes/blob/main/nats...

Basically just configure it with `{service-name}.internal` to find other instances of the service.

jabr

7 months agodiscuss

There is a `--no-install` flag on both `uc machine init` and `uc machine add` that skips that `curl | bash` install step.

You need to prepare the machine some other way first then, but it's just installing docker and the uncloud service.

I use the `--no-install` option with my own cluster, as I have my own pre-provisioning process that includes some additional setup beyond the docker/uncloud elements.

jabr

7 months agodiscuss

Do you have an example of what you mean? I'm not entirely clear on your question.

jabr

7 months agodiscuss

The `compose.yaml` spec for services let's you specify which machines to deploy it on, so you could target the database and web app to the same machine (or subset of machines).

There is also an internal DNS for service discovery and it supports a `nearest.` prefix, which will preferentially use instances of a service running on the same machine. For example, I run a globally replicated NATS service and then connect to it from other services using the `nearest.nats.internal` address to connect to the machine-local NATS node.

jabr

7 months agodiscuss

There isn't a cli function for adding a connection (independently of adding a new machine/node) yet, but they are in a simple config file (`~/.config/uncloud/config.yaml`) that you can copy or easily create manually for now. It looks like this:

    current_context: default
    contexts:
      default:
        connections:
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud
          - ssh: [email protected]
            ssh_key_file: ~/.ssh/uncloud

And you really just need one entry for typical use. The subsequent entries are only used if the previous node(s) are down.

jabr

7 months agodiscuss

I can only speak for myself, but I considered a few options, including "simple k8s" like [Skate](https://skateco.github.io/), and ultimately decided to build on uncloud.

It was as much personal "taste" than anything, and I would describe the choice as similar to preferring JSON over XML.

For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.

jabr

8 months agodiscuss

How does this compare to https://www.mooncake.dev/pgmooncake? It seems there are several projects like this now, with each taking a slightly different approach optimized for different use cases?

jabr

9 months agodiscuss

DuckPGQ is an interesting option, but unfortunately, that project hasn't been touched in a few months and does not currently work with the latest version of DuckDB.

jabr

9 months agodiscuss

A couple companies using Kuzu in products are talking about joining efforts on a community fork, including Gitlab and Kineviz. Possible future home of that work: https://github.com/Kineviz/bighorn

jabr

9 months agodiscuss

My best guess is the company was acqui-hired and will soon be working on implementing Kuzu's tech in a different database owned by the acquirer.

My _hope_ is that it was some IP issue with the University of Waterloo and a new company will appear shortly and pretty much pick up where they left off, but that's probably just wishful thinking on my part.

jabr

last yeardiscuss

AT&T

* https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm

* https://en.wikipedia.org/wiki/X86_assembly_language

comments