> I am now wondering if anyone has done a graph db where the edges are embedding vectors rather than strict terms.

Curious: how would you imagine it working if there were such a graph db?

I had the idea a few hours ago so I'm sure there are holes in this but my first idea is forming a graph where the relationship isn't a fixed label but a description that is then embedded as a vector.

First of all, consider that in a way each edge label is a one-hot binary vector. And we search using only binary methods. A consequence is anything outside of that very narrow path all data is missed in a search. A simple step could be to change that to anything within an X similarity to some target vector. Could you then search "(fixed term) is a love interest of b?" and have b? filled from facts like "(fixed term) is intimate with Y" and "(fixed term) has a date with Z"?

There are probably issues, I'm sure there are, but some blend of querying but with some fuzziness feels potentially useful.

Isn't this exactly what neo4j does for graphrag?

Is that vectors for edges or for searching the nodes? I’m talking about encoding the edges as vectors for traversal.

Yes you can do that with neo4j.

Interesting, thanks, I'll have to explore that.

Modern, but sane syntax (readable), good defaults (strong typing, null safety...), good-enough runtime performance, good APIs and tooling out of the box, cross-platform (also hot-reload on some, AOT). The list goes on, what specifics do you care about more?

Basho team was very kind to open source contributions in ~2011-12: I've written an open source Riak client in Dart, and they had sent me t-shirts (the quality ones that are rare today). Nice treats for a fun project :)

One of the postgresql client packages (posgres) is roughly 8 years old. That's how "client side" it ever was...

It sounds like you need a desktop workstation with replaceable extension cards, and not a mostly immutable laptop, which has different strengths.

Agreed but it will need to wait for now.

Clearly not all, that would be a different announcement.

Why do you think it must be one thing or the other? It can be better than Javascript, used for Flutter and app development, and also cross-platform compiled and used for backend.

Approval voting is just a different flavor of the same popular candidate tyranny. We need to be able to express support for non-duopoly candidates over the duopoly ones, and not continue to be held hostage fully supporting mainstream party #1 by the threat of mainstream party #2.

Unfortunately this devolves into geeking out over voting systems. Despite having the most popular support, Instant Runoff Voting is also a hot mess with its surprising nonintuitive outcomes. The way I see it, RCV/Condorcet is the way to go, regardless of the criticism that it allows for ties - it's criteria is straightforward and what most people would consider fair. Solve the ties with a tiebreaker IRV round (same input data type) or just a second election since they're going to be really rare with any significant population (how many times do we have ties with plurality?)

Hardly a nit when approval voting, unlike _any_ ranked-choice system, isn't mathematically shown to be inherently unsatisfactory.

Just pick your top 5 and it'll work out fine.

As long as you can answer a (long) series of "do you prefer A or B" questions, you can totally rank 82 people.

If I was voting in this election, I'm nearly certain I would not be able to answer that for most of the 82.

Well, if there's an A/B pair you can't separate, just pick either at random.

If my bottom 60 are all randomly shuffled then I haven't really ranked 82 people.

Note: the title is missing "unless the open source model evolves".

I submitted this, and opted to elide that part of the title, both due to wordiness and also because it doesn't change the headline: the "evolution of model" that McJannet is advocating is not in fact open source. He is, therefore, predicting an "OSS-free Silicon Valley" -- one way or the other. (I also think he's entirely wrong.)

That is the interesting part indeed. Perhaps there is a place for another type of license in between gpl/mit and full proprietary.

I wonder what that would look like. Perhaps it’s time. But the grey area is just so vast.

I'd imagine it looks a lot like BUSL: source is available, and fine for use in non-competing ways, but using it to compete against the commercialisation efforts that pay for primary development is not allowed. Basically every successful open source company other than Red Hat at this point has the model in one way or another.

That sounds reasonable indeed. But competing against the commercialization efforts is just so vague. It’s also a huge turn off for enterprises, they are already afraid of the GPL, I think enterprises will not touch BUSL code.

It’s nice for self hosters perhaps. But I for one am always thinking about how I can commercialize my self hosting skills (and have been somewhat successful here and there).

Enterprises are afraid of the GPL for libraries or OSS stuff they’re running but not paying for.

If they’re paying for a service because they need it (not so they can resell or repackage it in some way), I don’t think they’re going to be so picky about the license. They pay for plenty of 100% closed and proprietary software after all. The benefit of OSS/SA licenses in that case is debugging, being able to contribute patches, and continuity if the vendor goes bust. For those purposes, having access to the source is what matters, not the particular license.

I don't know I'd agree that it's vague - the triggering conditions in BUSL are instance specific so each instance requires evaluation. The HashiCorp provisions are perfectly clear.

What I do wish is that all companies who have this kind of license would also have a clearly priced, clearly defined "pay us X and you can use the OSS bits under this commercial license instead" model, for exactly the reason you describe though.

Is your work open source?