Oh the memories of that machine. UIdaho used one as a file server for the rest of the labs (home dirs were //snake/home/$user iirc, with snake = dn10k) and it was also available for use as a speedy workstation. Spaceball + 40bpp graphics made for some fun early forays into graphics programming.
Was also where I happened to hit ctrl-enter after the admin had neglected to flip it back into normal mode. During the middle of a class day. Chaos.
that's exactly how I did it when working on scsharp (https://github.com/toshok/scsharp). you gave it the paths to directories holding assets for starcraft + broodwars. 10 years on github without a dmca knocks on wood
The use of "self-hosting" was addressed in post. I think its use is actually right on the mark, but will grant you that it's slightly different than its use in the context of a static compiler written in the target language.
It basically means "able to host its own development". This means something different in different contexts, e.g. JS JITs "self-host" when some part of their builtin code is written in JS. We share that property with JS JITs, but in this particular case it means we can host our own build/test infrastructure. So we're using pyston to develop pyston. ergo, "self-hosting (qualified)."
---
We're definitely slower than pypy at present - we're only a small fraction faster than cpython after all on our benchmarks, and pypy is scary fast :)
I think we're still in the part of our work where the answer to the "big win with this approach" question is "we don't know." We're confident that we can/will be much faster than we are now, but we have different constraints than pypy, so it will always be something of an apples/oranges comparison.
Was also where I happened to hit ctrl-enter after the admin had neglected to flip it back into normal mode. During the middle of a class day. Chaos.