19 Jun, 2009, quixadhal wrote in the 1st comment:
Votes: 0
Ok, here's an idea I've been kicking around ever since I first heard the name MudOS. Until I first looked at it, I had no idea that MudOS was an LpMUD, I took it at name value… an OS that implemented a MUD on a computer. That sounded like a good idea to me, and it still does, even though MudOS has nothing to do with it. :)

The idea is simple. A mud does two things. It runs an elaborate state machine to implement your game, the details aren't important, other than to know that it's keeping track of the state of the entire game world and performing actions based on what players do. It also handles socket I/O and keeps players connected, sending their input to the appropriate parser to do stuff, and sending output back to tell them what's happening around them.

In many ways, this is exactly what your OS shell does. You connect to a machine via telnet/ssh/getty, it handles the socket I/O and authenticates you against a username/password/key database. Once authenticated, it spawns a shell and hooks it to your pty, which in turn is hooked to your socket. Your shell then provides you a command interpreter which figures out what you're doing and passes I/O back and forth between your pty and itself or a spawned process.

So, I'm pondering the idea of having a mud allocate a pty when you connect, so that you can get proper terminal handling, and I think to myself that your shell already does this. Why not use that? There's no real reason a chroot jailed bash shell can't do exactly what the normal parser of a mud does. As long as the mud server has write permission to your tty, it could send messages for asynchronous events, while commands like "look" would just be executed by bash… they would connect to the server and inform of what you tried to do while it returned the appropriate output to print.

The advantages are you can use your existing login system (ssh, telnet, whatever) to connect. You don't have to fart around with string parsing to break up arguments. In an environment where you're using an interpreted language, the files are directly accessible. You already have a user/group security system. Full-screen apps are possible, and even ones that have nothing to do with the game (IE: play nethack while nobody is on).

The disadvantages… you lose the one-process accountability. This makes it less popular for hosted games. If you give them a full copy of bash, they might do nasty things with the scripting support (while 1; do look; done).

Opinions? It's something different to argue about, anyways. :)
19 Jun, 2009, Runter wrote in the 2nd comment:
Votes: 0
quixadhal said:
Ok, here's an idea I've been kicking around ever since I first heard the name MudOS. Until I first looked at it, I had no idea that MudOS was an LpMUD, I took it at name value… an OS that implemented a MUD on a computer. That sounded like a good idea to me, and it still does, even though MudOS has nothing to do with it. :)

The idea is simple. A mud does two things. It runs an elaborate state machine to implement your game, the details aren't important, other than to know that it's keeping track of the state of the entire game world and performing actions based on what players do. It also handles socket I/O and keeps players connected, sending their input to the appropriate parser to do stuff, and sending output back to tell them what's happening around them.

In many ways, this is exactly what your OS shell does. You connect to a machine via telnet/ssh/getty, it handles the socket I/O and authenticates you against a username/password/key database. Once authenticated, it spawns a shell and hooks it to your pty, which in turn is hooked to your socket. Your shell then provides you a command interpreter which figures out what you're doing and passes I/O back and forth between your pty and itself or a spawned process.

So, I'm pondering the idea of having a mud allocate a pty when you connect, so that you can get proper terminal handling, and I think to myself that your shell already does this. Why not use that? There's no real reason a chroot jailed bash shell can't do exactly what the normal parser of a mud does. As long as the mud server has write permission to your tty, it could send messages for asynchronous events, while commands like "look" would just be executed by bash… they would connect to the server and inform of what you tried to do while it returned the appropriate output to print.

The advantages are you can use your existing login system (ssh, telnet, whatever) to connect. You don't have to fart around with string parsing to break up arguments. In an environment where you're using an interpreted language, the files are directly accessible. You already have a user/group security system. Full-screen apps are possible, and even ones that have nothing to do with the game (IE: play nethack while nobody is on).

The disadvantages… you lose the one-process accountability. This makes it less popular for hosted games. If you give them a full copy of bash, they might do nasty things with the scripting support (while 1; do look; done).

Opinions? It's something different to argue about, anyways. :)


It's an interesting idea but I'm more afraid about the nasty things someone can do that we're not going to think up. It practically removes any abstraction layer protection that generally all non-os programs have.
19 Jun, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I'm quite interested in the idea of treating the MUD more like a shell, for nifty things like tab completion, globbing, etc., however I wouldn't go so far as somehow embedding all of bash. For starters it seems like overkill. Secondly, and more importantly, the reason why it's ok to give users that much power on an OS is that, well, you're an operating system! You can schedule processes and do all kinds of fun stuff. If you were to do this at the MUD level, you'd have to reimplement all of that yourself.
19 Jun, 2009, elanthis wrote in the 4th comment:
Votes: 0
There actually is a game that does exactly this. I cannot for the life of me remember the name, but I recall checking it out some years ago. It was also database free, using files and locking to implement NPCs and objects, and (presumably) cron jobs to implement updates and AI. It can probably be found via Freshmeat or Sourceforge with some searching.
19 Jun, 2009, nrhtr wrote in the 5th comment:
Votes: 0
19 Jun, 2009, quixadhal wrote in the 6th comment:
Votes: 0
HAHA! Yep, that's the idea. I don't want to embed bash IN a mud, I want the mud to run as a big state machine with the users having paths that contain in-game commands instead of the usual tools.

If you wrote a custom shell instead of bash, and removed any direct editing commands, it would be secure in a chroot jail, no problem. Bash itself might be an issue because it allows scripting.
19 Jun, 2009, David Haley wrote in the 7th comment:
Votes: 0
If you start writing your own shell, it becomes a lot less clear to me what the advantages are.
19 Jun, 2009, elanthis wrote in the 8th comment:
Votes: 0
Advantages:

1) No need to write networking code at all, since you just use stock telnetd and standard I/O.
2) No need to write authentication code, since you ust /bin/login (possibly with PAM).
3) Automatic parallelism.
4) Easier time componentizing systems (than C, anyways).
4a) Automatica "garbage collection" of command data.
5) Use of OS facilities for data management and hierarchial structures.
6) Easy to use a mix of languages without developing bindings.
7) OS-enforced privilege separation between players, ACLs, and access control
8) Ability to use ncurses (or similar library) for developing MUD UI.

I could keep going with a little more time thinking about it. :)

Naturally, there are a number of disadvantages. I think most of those are pretty obvious, the biggest of which would likely be the trickiness of locking.
19 Jun, 2009, David Haley wrote in the 9th comment:
Votes: 0
I should have phrased it this way: what I meant is that it starts becoming a lot less clear that the advantages outweigh the disadvantages. Yes, you get lots of nifty things "for free", but I'm not sure if the cost you pay elsewhere is worth it.
19 Jun, 2009, elanthis wrote in the 10th comment:
Votes: 0
I think if one were to develop a solid set of tools for getting and storing data as well as sending and receiving messages, it would be just fine. The overall resource usage would be up, but given how most MUDs are lucky to hit 40 players these days, I'm not sure it matters. Really hard to tell given that nobody has fully implemented such a system to a fully playable and "production" state. If someone wants to take a shot at it, more power to them.
19 Jun, 2009, David Haley wrote in the 11th comment:
Votes: 0
Well, it also means that you need to have much more access to the system than you normally would; you basically need to have an entire machine (virtual or not) devoted to the MUD, which isn't an option for a lot of hosts.

I'd be interested to see how such a thing works, but I admit that I don't place enough stock in the idea to want to do such a thing myself given my limited time these days. :thinking:
21 Jun, 2009, quixadhal wrote in the 12th comment:
Votes: 0
Hmmm, so I was thinking about this a bit. The number one problem is security, and I think one way to solve a good chunk of that is to modify the shell (bash or otherwise) to not allow background tasks. If you can't spawn a background task, you're limited to only being able to loop commands… and that could be controlled by the commands themselves, or by the server they talk to.

Again, you'd want to be in a chroot jail, since you want /bin/kill to talk to the server and start combat, not kill a process. :)
21 Jun, 2009, Tyche wrote in the 13th comment:
Votes: 0
AberMUD, VaxMUD and Monster worked exactly this way.
Files were used as "semaphores" to control concurrent access.
Later versions of Aber do not.
21 Jun, 2009, quixadhal wrote in the 14th comment:
Votes: 0
I vaguely remember Monster using some special VMS file locking. :)

I don't think concurrency will be an issue for players. I was picturing player commands being things that were essentially front-ends to a server-side version. The player types "look bird", their shell would run the "look" command, which would get "bird" as argv[1], as usual. It would sanitize the arguments however it needed to and then pass them along to the server via a socket (tcp, unix, even udp). The server end would then process it, much like current servers do, but without having to do all the string parsing. The results of the look function would be passed back down for display.

You could avoid the passing back for display side if you require the server to be on the same machine (which is the intent), since all mud players could have pty's that are shared access with the server, and thus it could write directly. You could also avoid the socket interface for commands if you use rpc's, but then you do have locking issues and have a bit less security in place.
0.0/14