> But Ivan, no one forks opencog; almost all extensions are placed back into the core code base.
I'm aware of that. If someone forks the entire project, it would have been called some other name. I was referring to an imaginary system where the whole project would be a set of modules that work together, connected by well known set of interfaces. Each module could be modified or* forked out* in parallel with the original. It would be up to a user, which sub-forks she/he would choose to use to run the project, or to base her/his contribution on. Probably there would be a need for combination maintainers, something like persons that would choose different flavors of the project, and would propose their "deejay-combo" to the public, optimized for this or that use. Sub-fork combinations of low quality would be avoided, while really useful ones would live on. Just a bit of brainstorming in a direction of decentralization. The goal is to have industry-strength project abilities with liberal multi-user maintaining policy. It is on my long-term to-do list, but I could share my thoughts with someone who wants to implement it sooner. Thank you all for your patience :) 2017-10-03 4:33 GMT+02:00 Linas Vepstas <linasveps...@gmail.com>: > Hi Anastasios, > > Yes. But first: complaining that opencog is written in C++ is like > complaining about the fact that the linux kernel on your cellphone is > written in C. Who cares? It does not affect 99.9999% of all cellphone users > because they do not write kernel device drivers. > > Think of the atomspace as being like an OS kernel. You probably should > not be writing new C++ extensions it. Instead, you should be writing apps > for it. The apps are where the action is. > > So far, we've offered maybe half-a-dozen app APIs for it, with varying > degrees of success. > > Having an instance on the cloud would be great, where people could spin up > an instance, and log into it. I've long long wanted to do this; hell, I > could just throw an old PC onto my internet connection. I don't have time > to mess with this. > > For cloud-cog, the only thing available would be the app API's, and maybe > that would make the bitching about C++ stop... > > --linas > > On Mon, Oct 2, 2017 at 6:47 AM, Anastasios Tsiolakidis < > hellene...@gmail.com> wrote: > >> Well isn't OpenCog having a busy weekend :) As a lurker I have already >> expressed my dissatisfaction at "advanced C++" which is the trend in the >> project, and would probably carry over my disapproval of "idiomatic C#". >> There is absolutely no reason for the coding to be more difficult to >> comprehend that OpenCog's design itself. If anything, the code should make >> plain and simple what the bloody design is trying to do! Now, my particular >> wet dream would be to see people pulling together their own "free >> resources", like the free tiers at AWS, Google Cloud etc, to create a >> hive-mind. If somebody was brilliant enough to throw away big chunks of the >> code and instead achieve (some of) the same results with a DB of sorts, AWS >> lambda etc, that would be quite something. Then, for the parts that don't >> fit the "cloud" box, if someone could come up with the "CloudCog", some >> probabilistic graph, inference engine or whatever is missing from the >> garden variety PAAS and SAAS, then we could really be heading somewhere. I >> don't know much about the project beyond the demos, but I do believe the >> project is being hurt by the general unavailability of a constantly running >> instance that "does something", whatever that maybe, and somehow can be >> accessed by the public, eg through an API. Presumably this new hedge fund >> thing may be the closest OpenCog has come to being a 24/7 system, and Ben >> will probably tells us if he finds out a better way to do things with and >> without this codebase >> >> AT >> >> -- >> 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 post to this group, send email to opencog@googlegroups.com. >> Visit this group at https://groups.google.com/group/opencog. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/opencog/2668e4aa-5324-4a66-9786-c795daad157c%40googlegroups.com >> <https://groups.google.com/d/msgid/opencog/2668e4aa-5324-4a66-9786-c795daad157c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *"The problem is not that artificial intelligence will get too smart and > take over the world," computer scientist Pedro Domingos writes, "the > problem is that it's too stupid and already has." * > > -- > 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 post to this group, send email to opencog@googlegroups.com. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/opencog/CAHrUA35uH4eecM_zh%3DvnNXwMtTUwEkv9qSXOGBCQjgw1kd > 0How%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAHrUA35uH4eecM_zh%3DvnNXwMtTUwEkv9qSXOGBCQjgw1kd0How%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6X_KLTw1t1HaX1YK4TDPuvGNScUaN%3DVE0ncvKcQNJZufw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
