1,115 karma · joined March 12, 2009
I loved this game! I actually had the Forth package for the C64 also but I never put 2+2 together that the game was made with it.
This is back now with WASM!
https://en.wikipedia.org/wiki/Asimov's_Guide_to_Shakespeare
It's like 800 pages, I haven't read it but I think I'll keep that one. Seems like it might be hard to find another physical copy. He was definitely prolific on a number of topics.
https://github.com/qemu/qemu/blob/v2.9.0/docs/replay.txt
That said, I was not aware of it until I saw this post, and I definitely want to play around with it.
The people who bought it from me tried to flip it but walked right into the chainsaw of 2008 and had to sell it at a loss. I could have bought it back for even less than I paid for it the first time a year later! Whoever did buy it got a great deal because now 15 years later it's worth $1.3 million and I feel like I should have just kept it. I definitely haven't managed to save $1m in the last 20 years.
I was asked to do this as an interview question at google! It was about log file processing not math (sample an infinite log file), and I thought my answer was ok? But that's why I don't work there so I am really enjoying this whole thread.
I think the whole stack of operating systems and tools that assume that this is possible get in trouble when it's not possible. I don't want my computer to become a locked down sandbox but it seems like this is where we are headed.
But it does seem kind of ugly of us as a species to preserve them as a species for hunting.
If you've ever had to cut and paste a 50 line docker run command snippet but you forgot that one volume mount or port or ENV var that someone added a dependency on last week then you pretty quickly realize just doing complex docker things by hand is a pain. Another example, if you have a script that you want to run to fetch the latest authentication token from a vault after the container launches because you don't want to store it inside the container. Sure, you could write a bash script to run all these steps inside the container after you launch it but it's nice to have a config file to share with another dev and just say: use this.
And the secondary benefit is that having a config file for the editor (like VSCode) so that plugins can manage all of that stuff better. Generally a dev container runs the VSCode Server, and they know how to talk to each other which can make remote development easier. For example, now I can launch the same dev environment locally or on the 56 core xeon 1TB ram server at the office and it's exactly the same as far as the editor is concerned.
It looks like this project is an alternative to the VSCode Server. My team generally uses docker-compose for this since not everyone uses VSCode.
https://github.com/OpenInterpreter/01/blob/main/software/sou...
There don't seem to be many skills defined in this repo though, but I didn't look too hard. This software is the server, and then they have a small remote device that can talk to the server and it appears to use ngrok for that.
[replying to comment here]
I totallly agree that the term "OS" is used for a lot of projects that are not actually what I would call an OS. My own employer is guilty of this. :) Yes, this seems to be just like UFO, and Rabbit, and other similar projects.
Anyway, in my experience my dad took a few years to do that kid stuff and it really had a positive effect on our relationship.
For such assignments, which are generally uncredited, he commands a fee that he acknowledges is “insane”: three hundred thousand dollars a week. Most jobs last a few weeks.
His last project was trying to write a comprehensive history of Japan for wikipedia. I helped him upload it and it's buried in Wikibooks somewhere now and I like to think that some of his work is going to end up in the training material for some future AI like a ghost.
For me, the best thing about Docker is that it's brought the average developer experience from "oh, I think I have an install.sh for that around somewhere" to mostly repeatable builds that are mostly self documenting. Any time a tool is self documenting it's a win. If you want the cake, you have to write down the recipe. That's huge. It's forcing lazy devs (which we all are) to just write it down. At this point the amount of "weird bearded guy tribal knowledge" that is now documented in a Dockerfile somewhere is a treasure trove.
Things still break all the time for a million dumb reasons but as a least common denominator it's a great place to start. It's not a solution for everything and it sounds like that's what this article is about. Docker+Compose is not great for everything, so don't use it for those situations. But it's so much better than what was before.