HackerTrans
TopNewTrendsCommentsPastAskShowJobs

jabr

no profile record

comments

jabr
·3 bulan yang lalu·discuss
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 bulan yang lalu·discuss
State replication is currently based on corrosion: https://github.com/superfly/corrosion
jabr
·7 bulan yang lalu·discuss
> 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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
Do you have an example of what you mean? I'm not entirely clear on your question.
jabr
·7 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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
·tahun lalu·discuss
AT&T

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

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