(This project isn’t ready for prime time but it was a sketch of an approach to mitigating the downsides of integrating through the database, in order to unlock the upsides).
Electric DB | London and Istria | Remote | Full time and part time | https://electricdb.net
Electric DB is developing a next generation global database.
We’re hiring product engineers, database engineers and a developer advocate.
Our challenge is (1) to deliver a world class developer experience for a managed geo-distributed database service whilst (2) pushing the CAP theorem and latency <> consistency trade-offs to their limits.
If you care about both (or specialise in one and are intrigued by the other), have relevant craft skills and the mindset to join an early stage startup then we’d love to chat.
I think to keep it hosted will require tending to the bitrot. We don’t know how the web and computers will change but we do know they will change.
So a succession of people (or, later, robots) need to be incentivised and resourced to maintain it.
A foundation is one idea. But I quite like a viral clause in your will. So, to inherit, your heir needs to (a) maintain your digital legacy and (b) put an equivalent clause in their will, and so on. Maybe it depends on the value of the inheritance but it might be a way to secure a few generations.
Then you could also stipulate that they should do anything they can to use the resources of their time to further secure the digital legacy. You could also make the responsibility always joint and several across all children / heirs.
This is very interesting and it strikes me that things could be more balanced if pro-rata rights decayed if the investor is not active.
So similar to vesting for rights — a founder / employee needs to continue to be active to continue to vest. Ideally an investor could continue to be active to continue to exercise pro-rata.
It’s pretty hard to enforce / codify “active” for an investor though and could just result in time wasting by pretending to be involved helpful when just coasting. Was that intro genuine or just designed to protect the pro-rata?
RTK GPS is used as a second factor to vision in these machines. It’s just not good enough to target with as a sole / primary factor in the real world though. Bit of drift and whoops, $30,000 of crop gone.
Lasers are not used because they’re expensive and dangerous. And Co2 lasers (as per the machine in the article) are powerful but super fragile.
Water shooting around at high pressure is in no way efficient or easy to handle.
Thanks for posting this, very interesting. The linkedin profile pointed to a youtube video (unlisted) that was pretty interesting and covered how they could calculate eye safely using simple math that indicated the safe distance was 2 meters away. They appeared to be using blue LEDs at high intensity to char-or-inactivate weed photosynthesis.
Supabase’s realtime library consumes the logical WAL and provides a Phoenix channel + JavaScript API to subscribe to matching events from it:
https://github.com/supabase/realtime
These approaches rely on acking the WAL to confirm data has been processed. It’s simpler than running Debezium / Kafka for “zookept” CDC. However, they are “at least once” at best and it’s easy to shoot yourself in the foot so think twice before relying on this kind of thing for a real application.
Materialize is nice — TAIL is a lovely abstraction and their data ingest uses Debezium under the hood. That said, I believe their Postgres binlog source is still alpha / under active community dev.
Nice, I've actually extracted out supabases WAL subscribe bits to use alongside with Hasura so that I can react to insert, update and delete events right in Elixir.
Looks like you're doing something similar. I'd love to see this extracted out into a library by the supabase team.
> I'd love to see this extracted out into a library by the supabase team.
Supabase cofounder here - I'll raise this with the team. Feel free to email me if you have any specifics around how you're using it so we can make sure it fits your use-case (email in my profile)
GitHub is a “social coding” platform that provides collaboration features (access control, issues, etc) on top of Git.
This is a social coding tool that provides collaboration features on top of Git.
It provides a desktop app because it’s peer to peer. That’s an advantage over a web UI for developers looking to avoid a dependency on a centralised third party.
You are free to continue to play in walled gardens but this is very much an alternative to that.
(This project isn’t ready for prime time but it was a sketch of an approach to mitigating the downsides of integrating through the database, in order to unlock the upsides).