A Python library for writing distributed self-replicating programs

This, from https://news.ycombinator.com/item?id=5397797, posted in 2013 comes very close:

> I did this in my machine learning class. I started by simply coding up requirements for numerical functions (in the form of test cases), then set up a PHP script that would Google each function based on the keywords in my comments, and try to run any code on the resulting links (in a sandbox) against the requirements, seeing if it worked heuristically. Usually one of the top 5-10 pages of results results would have code that worked, though of course this is because I commented with the right key words to begin with.

> With a little recognition of code markup and trying different combinations of variables it did remarkably well: by my senior year of college it was pulling about $3,000 per month in consulting fees off of Odesk. It never accepted jobs worth more than about $50, nor did it ever get more than 3 stars out of 5 mostly due to non-working code, however it was considered highly timely and a great communicator.

> I realized that people were using it to save themselves Googling. I wondered what would happen if it went a step further and simply both included Google results, and divided out projects by their paragraphs (i.e. simply submit a paragraph of a large project as though it were a small independent project), and if clarifications were requested, send the other paragraphs.

> This actually let it outsource $200 Odesk projects to Elance as a handful of $20 projects, and by the grace of God somehow still managed to swing 3 stars.

> To be fair, it was mostly mediating, and mixing in Google results. I included a hill-climbing algorithm to optimize reviews and revenues, based on all the magic variables I had in the code, such as the number of Google results to include.

> This was really, really stupid of me.

> At first, I just noticed that it had actually decided to completely stop not only writing code (ever) but even so much as do a Google search!

> It would only mediate and quote verbatim, like some kind of non-technical manager.

> Okay, whatever. To me this didn't make much sense, as Google queries are free. It was only when I noticed that the whole script was running on the free VPS server I had a backup on that things clicked! Of course, on Amazon it uses resources. The free VPS server didn't let it reach external sites like google properly, but it could still save money by simply mediating emails and doing nothing else.

> By now I had started moving on to doing my own consulting work, but I never disabled the hill-climbing algorithm. I'd closed and forgotten about the Amazon account, had no idea what the password to the free vps was anymore, and simply appreciated the free money.

> But there was a time bomb. That hill climbing algorithm would fudge variables left and right. To avoid local maxima, it would sometimes try something very different.

> One day it decided to stop paying me.

> Its reviews did not suffer. It's balance increased.

> So it said, great change, let's keep it. It now has over $28,000 of my money, is not answering my mail, and we have been locked in an equity battle over the past 18 months.

> The worst part is that I still have to clean up all its answers to protect our reputation. Who's running who anyway?

Edit: The first answer by bo1024 is gold as well:

> Don't feel bad, you just fell into one of the common traps for first-timers in strong AI/ML. I know some lawyers in Silicon Valley with experience in this sort of thing, and they say that usually by now the code has rewritten itself so many times that the original creator can't even claim partial ownership; the best thing to do is generally to cut contact, change your name and move on. Look on the bright side -- your algorithm is probably now leading a happy and productive life trading for Goldman Sachs.

Ahh, amazing work. Your original blog posts describing the workings of Mitogen and the pitfalls you've had to avoid were incredibly interesting. Thank you so much both for the project, and for the fascinating documentation of the development process.

>The system the library was intended for has never been described.

That's interesting - could you, perhaps, describe it a little?

Could you compare mitogen to docker swarm? Also, I haven't seen it mentioned in the docs, does mitogen set up a python environment on target machines? Or does it assume target can run python?

I have not looked at the code yet, but looking at the philosophy of constraints as seen in the manual, I would say that you did a very very good job! Zero dep, support for old python, support for egg like apps,... I'm really amazed because, the current trend is to have zealots that only want to use and support last versions and take whatever shitty dep they can find that ease their life. But in the real pro dev life, it is brick as good as yours that we need!

The problem with ansible-pull is that you can no longer use it coordinate changes across machines, which is very useful for deployments for example.

I mean sure, just copying Ansible to the target machine and running it locally 'fixes' things, but at what point should it still be considered Ansible? You lose so much with -local, at least:

- centralized vault, target nodes need access to secrets

- "serial:" no longer available, you can't do rolling upgrades any more

- "hostvars" no longer available, you can't query facts from other machines

- no centralized trigger mechanism, status or failure reporting

etc.

Put another way, you could claim ansible-local fixes things for the same reason you could claim bash is network-aware agentless automation because you can copy shell scripts between machines

B can be A, without A being B ;)

I had this exact example in mind tho FWIW. It is an ongoing research topic whether or not viruses are life, but the analogies/similarity are overall worth noting.

Maybe on a biosphere level, or even on a more micro ecosphere level, all sentient systems really exhibit the same properties as a virus in the local context, for that system, even if entities in that system do not have the consciousness to be able to make that determination. Certainly our effect on the planet Earth since the Industrial Era should make it worth it to endeavour this analysis!

So they're kind of like an abstract base class of life that is missing an implementation of metabolize()

I don't think trying to shove this model into a gradient-descent framework makes the most sense here. I'm an ML (industry) researcher and I highly doubt that AGI will be achieved with gradient descent on neural networks alone. Those may play a small role somewhere in the stack but the orchestration and reasoning will be managed by something else entirely. Neural networks today are fancy MLE machines -- nowhere close to reasoning machines, which require an "understanding" (whatever that means in this context) of dynamics with respect to the environment.

Seems more appropriate to start with a population of agents who reproduce at a rate proportional to their recent rewards, and allow them to die off at a rate inversely proportional to the same, a la a continuously-evolving genetic algorithm setup. You may have to modify the reward function to disincentivize behaviors which cause systemwide collapse, but that goes without saying.