The "mudlib" code was sandboxed in a 100% secure restricted mode where all access to resources (disk, network, etc) can be abstracted away? Python doesn't have such a mode. Ruby doesn't have such a mode. I'd be surprised if Pike had one which cuts the mustard.
I was talking with regard to a replacement driver for MudOS. I see the DikuMUD argument as a straw man, that it relates to the scenario where the scripting language "driver" is in the same language as the "mudlib" and there is no sandboxing. More of a library or framework to build upon, where bleed-over is generally inevitable.
Proper experience of a language allows one to see the ways in which it can perform certain tasks. I will not comment overly for Python or Ruby as they are outside the scope of my original comments (although sandboxing in ruby is quite possible). Theatrics of promised surprise aside, I will answer:
Yes, the mudlib code was able to be sandboxed in a (as a computer security professional, I hate saying 100)% secure restricted mode where all access to resources (disk, network, etc) can be abstracted away. Pike allows you to call the internal compiler to compile pike code through the application, when doing so you can specify a custom-built compile handler, I used this compile handler to lock-down and over-ride internal functions to pike by restricting access to any function but those I explicity specified in any code compiled by the 'driver'.
As a basic example I've just chopped up bits of code from mine and the following (incomplete) example would create a compiler handler that only allowed the following:
array_sscanf,
backtrace,
crypt (over-ride mapped to the custom_crypt function in the driver),
write (over-ride mapped to send_message function in driver), and the usage of the
== and
!= operations.
mapping comp_map = ([ "`==":`==,"`!=":`!=, "array_sscanf":array_sscanf,"backtrace":backtrace, "crypt":custom_crypt, "write":send_message ]);
private object compile_handler = class {
mapping(string:mixed) get_default_module() {
return comp_map;
}
mixed resolv(string id, void|string fn, void|string ch) {
throw( ({ "Error in program : "+id+"\n", ({ }) }) ); /* Throw it off, it's already in backtrace */
error( sprintf("%O %s", id, "Problem with compilation.\n"), id );
}
}();
object compile_object(string file, void|int user) {
<...
verify file, create object reference number, load_file, etc
...>
newLoad = compile_string(newCode, file, compile_handler);
newOb = newLoad();
<....>
return add_global_object(newName, newOb, obj_cnt, creator, time());
}
Given this, i'm fairly certain that pike has the capability to sandbox effectively in a .. mustard cutting... way. I'm not quite sure where you gathered your information for reliability, but that argument isn't even worth going into here. It is similar to me insisting my grandfather use the internet for e-mail, he assures me that the internet is unreliable and the postal service is the way to go.
Your comment about ease-of-use doesn't make much sense to me. In the current state of LP there is not any more opacity than there would be in a scripting language. The driver needs to be compiled, this includes (in a few cases) modification of files in the source directory, and sometimes Makefiles, to make sure that your MUD works properly.
The same applies to a scripted driver, it resides in a separate directory from the lib and the user doesn't generally mess with it. Their interaction with the driver only has to be "pike ./driver/main.pike" or "./startdriver". I would argue that for a user that isn't loaded down with compilation tools, the scripted driver would be less complicated:
1. Install Pike
2. Unzip Mud
3. cd ~/mud
4. ./startmud
Perhaps you are assuming that much of the game-logic would have to be incorporated into the game driver? That's simply not the case, just because the game is written in the same language doesn't mean the logic can't be abstracted from the driver. Especially with the sand-boxing technique demonstrated.
Kaylus
p.s. Grammatical mistakes likely, this post has been something I've been typing in the background while actually working ;-)
