On Thursday, 11 November 2021 at 16:41:34 UTC+1 amirouche...@gmail.com wrote:
> Disclaimer: I do not want you to think that I want to be rude: please > take time to respond, it seems you misread or read too quickly or > something, what I write. And, please do not hesitate to ask me what I > mean, English is my fourth language (I mix grammar between all the > languages I know), even if that's the one I practice the most > nowadays. > > Le mar. 9 nov. 2021 à 18:07, Linas Vepstas <linasv...@gmail.com> a écrit > : > > > > On Tue, Nov 9, 2021 at 3:44 AM Amirouche Boubekki > > <amirouche...@gmail.com> wrote: > > > > > > > > > > Rocksdb is a serverless, single-system key-value database > optimized for SSD disks. It has C bindings, and it's fast. For me, simple > and fast are highly desirable properties. > > > > > > > > > So is wiredtiger https://source.wiredtiger.com/ but GPLv3 > > > > > > > Is wiredtiger actually serverless? > > > > > It has no network component. It has a notion of table, but that is > an optimization. You can use it like rocksdb with a single table, with > single key-column and a single value-column. > > > > > The only drawback is that it is difficult to work with if the > dataset does NOT fit in RAM. > > > > > > Linas replied: > > > > > > > The AtomSpace wants RAM. Because the AtomSpace is an in-RAM > database. So using something else that *also* wants RAM is stupid: it just > means that I have to buy a computer with twice as much RAM. I've walked > down all of these roads before. > > > > > > I am not sure I understand: will the new symbol expression database > > > work along the current AtomSpace? > > > > What "new symbol expression database"? I don't know what you are > > referring to here. > > I read that symbol-expression is s-expr, I used to call it > scheme-expression, but I think symbol-expression is a better fit. > > > > > > In any case, whether it is RocksDB, wiredtiger, SQLite, Foundationdb, > > > or whatever. > > > > [...] > > > > > I do NOT want to have TWO RAM-hungry systems running, both of them > > competing for the same resource. > > > > OpenCog is a very large and difficult project with the goal to build a > software capable of tackling all tasks that only humans can do at this > time, and with the ability to adapt to new tasks, while considering > the 4 laws of robotics [-1]. > > [-1] > https://wikiless.org/wiki/Laws_of_robotics?lang=en#Isaac_Asimov's_%22Three_Laws_of_Robotics%22 > > > I can not find a good narrative about the subject: it seems to me AGI > is much harder than ITER [0][1]. The human-year total investment is > beyond the 100 for ITER, maybe 100,000 if you take into account people > that are not scientists or engineers. > > [0] https://www.iter.org/ > [1] https://wikiless.org/wiki/ITER?lang=en > > We need to assume people have gone mad, and others will become mad > trying to solve the problem of AGI. > > OpenCog should take the maximum care when asking or suggest people to > invest their time and energy into this and that. I know, you old > timers have invested more time than me on the subject. > How does this part relate to the earlier discussion? Why are you comparing a software project to a huge construction one? > > > By contrast, if the backing store to the AtomSpace is a disk drive, > > then when I go to save something, I DON'T use more RAM. I just use > > some disk. Disk is cheap. That means that most of the RAM in the > > system is available to the AtomSpace. Yayy! > > > > > The decision must not be settled lightly, > > You cut off the part where I wrote opencog needs to take the time to > review, audit, benchmark existing tools, material [and publications, > and make that in the open]. > > > > > Why make a decision at all? The AtomSpace currently has five different > > storage nodes (file, postgres, rocks, and two cogserver variants) > > (actually, seven: two prototypes that work, but were abandoned). You > > can use all five at the same time. You can copy atoms from one to > > another to your heart's content. You can even do queries across four > > of them (the file backend does not support queries) > > Consider all code is garbage whether it yours, or someone else. > > ONE developer with a good attitude, mood, and agency can change a > whole enterprise [2]. > > [2] https://danluu.com/culture/ > > > > > Add one more storage node for WiredTiger, if that makes you happy. > > It's not hard. It's under 2KLOC of code. Closer to 1KLOC, if you don't > > count GPL copyright boilerplate and verbose documentation. You could > > code this up and test and debug it in about 1-3 days (well, I could. > > YMMV) This is simply just not that hard, not worth hand-wringing or > > shedding tears over. > > The problem is not only about the coding process, it is coding the good > thing. > > > > > I was under the > > > impression they were clear goals and use-cases for opencog, > > > > Sadly, there are not. > > > > I have a hot take on that. We should narrow the goal for the immediate > future, something like 5 years, and focus on improving the culture > inside OpenCog such as doing things more in the open (e.g. giving more > access to write on the wiki; having more open-access / open-science > litterature), build tools (tools for thoughts, intelligence > augmentation) and curriculums to help with the onboarding new > developers; that will help to reach both end-users, developers, and > money. > What is giving write access (and to whom) supposed to do? Papers are posted on arXiv. What sort of “build tools” are you talking about? There is no “onboarding” or end-users, or developers — OpenCog is a *research* project, it’s not some sort of framework that you can apply to your business problem... > > > > my > > > recommendation is to extract from those hardware and software > > > specifications, and quality metrics, then benchmark https://okvs.dev > > > and dbms. > > > > The link https://okvs.dev just takes me to a wikipedia article. I'm > > sure Rocks is an okvs db. It kind of says so. > > Yes, that is that. And after 10 years of research, I am convinced OKVS > are a VERY good tool. > > But rocksdb... it depends... > But it’s an OKVS which you said is good, so what’s the point here? > > > > > The benchmarks are at https://github.com/opencog/benchmark These > > include a copy of the gene-ontology data from agi-bio, and a copy of > > some natural language data. > > What can I do with that? > > > > > Maybe something like (query ?x (foo bar ?x baz)) to find all lists > with four items, three of which as shown and the fourth unknown... would > this be an OK API? Have you seen anything like this? any suggestions? > > > > > > It looks like the symbolic expression database you built > > > > Heh. I didn't build it. Andre Senna and a bunch of Brazillians did, > > twenty years ago, under the supervision of mad scientist Ben Goertzel. > > All that I did was to work it, make it, do it, harder, faster, better, > > stronger, more than before. > > Faster at doing synthetic queries solving no real world problems? > Faster at doing things that provide infrastructure for other OpenCog projects. If you don’t consider figuring out AGI a “real world” problem then this is a wrong place for you... > > > > > Sometimes, it's worth celebrating anniversaries. The AtomSpace is > > twenty years old, I believe. > > > > That is great, but... we are not done yet :) > > > > looks much > > > like what I call a 'General Tuple Store' where every object of the > > > database is a tuple of arbitrary length made of "atoms". > > > > General s-expression store. Because each element can be another tuple. > > > > General JSON store, because each element can have a name. > > > > General abstract syntax tree store. Because each element stores trees. > > > > General python store. Because python is just syntax trees. > > > > General programming-language-X store, because all programming > > languages have syntax trees. > > > > It's general. That's the point. > > Maybe I am completely missing the point and I just made a fool of > myself. You're laughing at me... > I don’t get what’s the point of this whole conversation? What are the postulates exactly? That there should be a new storage backend for AtomSpace? Some organisational changes? These should get sorted into separate threads. Sorry but this looks like a mess. > > -- > Amirouche ~ https://hyper.dev > -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/1cb99c10-d1ef-4ef7-8f6b-787f8b68a212n%40googlegroups.com.
