Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
LukeEF
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
25 ms
·
151.
▲
by
LukeEF
6y ago
I can understand the motivation - AWS' approach, particularly to elastic, has been pretty awful, and migrating away from Apache/GPL/MIT is like a coming of age for the big databases (Mongo, Cockroach, Elastic...) - but callin
152.
▲
by
LukeEF
6y ago
TerminusDB, Crux and Grakn are other databases that use Datalog variants. Becoming a big thing.
153.
▲
Easy Versioning CSVs in a Database (with powerful query)
(terminusdb.com)
3 points
by
LukeEF
6y ago
|
0 comments
154.
▲
by
LukeEF
6y ago
I think the general feeling in the GNU/FSF is that if you are not using GPL, use Apache 2.0.
155.
▲
by
LukeEF
6y ago
We thought about the Eclipse Public License in advance of the shift. There is a very persuasive member of our community who argued in its favor. In the end, it is ease of recognition that swayed us to Apache. If you have to forward for appr
156.
▲
by
LukeEF
6y ago
Yes - as you mention I wrote about it in response to another point. Most of the external contributions to TerminusDB have been to the clients. The python community in particular has contributed extensively to that TDB client. The JS and pyt
157.
▲
by
LukeEF
6y ago
We did think about that, but our economic model is to focus on income for SaaS collaboration through TerminusHub. We are a distributed revision control database - so the model is a bit like git and github (only they piggy backed on an alrea
158.
▲
by
LukeEF
6y ago
Yes! I didn't mention, but I contacted all contributors directly over the last month or so and asked for permission to re-license their code. We only went ahead with the change when everybody had signed off on the shift. In fact, all t
159.
▲
by
LukeEF
6y ago
In our experience, all of the contributors were happy to give permission to re-license the code. They generally believed in the project (that's why they contributed) and wanted TerminusDB to be as successful as possible - if the core t
160.
▲
by
LukeEF
6y ago
the intro to the Octotree Github thread basically sums up open source perfectly!
161.
▲
by
LukeEF
6y ago
That's really good to hear - and it is exactly the sort of situation we had in mind when we started discussing the license shift
162.
▲
by
LukeEF
6y ago
Luke from TerminusDB here. As we struggled with this decision (it feels a bit like leaving behind an old friend), I found this deck very helpful - especially as it really highlights how many other great projects have struggled with similar
163.
▲
by
LukeEF
6y ago
TerminusDB co-founder here. Hope you find 4.0 release of TerminusDB useful/interesting. We think it’s a step towards our vision of a general-purpose tool for data & content management and collaboration. We’ve extended the revision
164.
▲
Show HN: TerminusDB 4.0 'Data and Content Management in a Box'
(terminusdb.com)
19 points
by
LukeEF
6y ago
|
1 comments
165.
▲
by
LukeEF
6y ago
But why do they do it so badly? Seems like they have the engineering muscle to put out a great reinvention of a document db, a time series db, a graph db... but each is relatively poor to the other services on AWS. Is it the combination of
166.
▲
by
LukeEF
6y ago
that is probably fair, I suppose comparing to the python world the financial folk soak up a lot of talent, but the open source ecosystem is stronger and better than ever.
167.
▲
by
LukeEF
6y ago
Having developed and launched a database (TerminusDB) built on a Rust core, this makes me slightly nervous. Feels like the evil empire will bring both great riches and great peril to the fantastic Rust community (part of the reason we picke
168.
▲
by
LukeEF
6y ago
Áed mac Bricc literally had other people's headaches - nightmare superpower.
169.
▲
by
LukeEF
6y ago
agree wholeheartedly - trying to solve that problem in a general way so nobody else has to have the headache (but, as you can imagine, there is a lot of complexity and detail in getting to something general and usable)
170.
▲
by
LukeEF
6y ago
It seems to me that we need local and sync for this to work well. Make your changes locally and either sync behind the scenes automatically or when you push 'commit'. Many applications (like notion and a bunch of the other browser
171.
▲
by
LukeEF
6y ago
Luke from TerminusDB here - we've been building automatic import and versioning features for CSVs over the last number of months. Just went into canary release actually. Agree very strongly with the benefits and problems of CSVs in the
172.
▲
by
LukeEF
6y ago
We currently have merge using rebase, with optional "query fixup" to reconcile changes. We are currently experimenting with various automatic fixup strategies for different use cases. We also intend to have a full git-like merge
173.
▲
by
LukeEF
6y ago
Agree that the solution on the site need to be changed! Don't know Day/Hypercore - do you have a link? I couldn't find (or at least I couldn't understand what I found!)
174.
▲
by
LukeEF
6y ago
You speak my pain... took so much pain to overcome these problems when delivering TerminusDB... taking best ideas from blockchain, git and rolling them all together... this white paper we wrote might remind you of past suffering... https:&
175.
▲
by
LukeEF
6y ago
TerminusDB and Hub (co-founder here) is offline first open source data collaboration software. We built the service so you can work offline for as long as you want and then resync when you're online again. We always felt this was the m
176.
▲
by
LukeEF
6y ago
Yes - the server is in SWIPL and the distributed store is in Rust. Great combo we think. We tried to take some of the best ideas from the semantic web and make them as practical as possible. Great to hear that people are getting knowledge g
177.
▲
by
LukeEF
6y ago
RDF triples turn out to be a crucial part of the architecture as they make describing deltas really straightforward. It is just these triples were added and these triples were taken away. Performance is good - you get a degradation in query
178.
▲
by
LukeEF
6y ago
One comment on using git, isn't there a pull:push bottle neck that means it can't service any workload that has any write rate greater than (say) one write every 30 seconds. Write is subject to interpretation of course given commi
179.
▲
by
LukeEF
6y ago
A decentralised revision control database revolution is brewing!
180.
▲
by
LukeEF
6y ago
TerminusDB (co founder here) was partially inspired by the git scraping approach to the revision control for data problem. We built a database that gives you all of the functionality of git, but in a database so you can query and with a com
More ›