Author Topic: driver rewrite  (Read 16935 times)

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: driver rewrite
« Reply #30 on: July 25, 2008, 10:08:03 pm »
I see scripting languages as being more complicated and unreliable.  Consider the standard LP driver.  It is a binary which provides a programming language and environment.  You don't need to care how it works, only that it does in a stable manner and has for years.  Replace that solid opaque layer with an open one composed of a scripting language, and now the reliability and complication of driver workings becomes the problem of everyone who uses it.

Nope, that doesn't logically follow at all.  The reliability and complication becomes the problem of everyone who MODIFIES it.  Look at the DikuMUD world for a plethora of examples of how drivers, written in C, can be modifed to become unstable and unreliable.

My feeling on the public acceptance of applications written in scripting languages, is that they don't have the reputation of quality which binary applications have.

If you had posted that in 1988, I'd have believed you.  But back then you tended to run binary applications on servers via remote connections and glass terminals.  It isn't even really proper to call them "scripting" languages these days, since they aren't used to whip up quick batch scripts.  Do you consider Java to be just a scripting language?  How about Visual Basic or any of the other .NET languages which are used for about 80% of the applications written in the last 5 years?

Anyway this thread is about making a better licensed MudOS-compatible driver if I recall correctly and sure you could make some completely different project, as you propose, but it is of no interest to me at least.

Yes, this thread is about making a MudOS-compatible driver.  I believe wodan wished to code it in LPC itself, with C++ as a target for code generation.  IE: write the driver in LPC and have it generate C++ code of itself which you could then compile.... much like the original gcc project which required the host OS's C compiler.  I remember those three-pass compile sessions well....

Nowhere was it suggested to just rewrite MudOS to avoid the license, although that would be a nice side benefit.  If that were the only goal, I'm sure someone would have done so already.

Personally, I advocated using .NET because it would bring an LP driver into the "modern era", if you'll pardon my vulgarity.  Adding LPC as a .NET implementation would allow you to then write a driver using any combination of .NET languages you like, wherever they're appropriate.  Yes, you still have to have an LPC interpreter, but that could be coded in LPC itself if that's the desired goal.  If part of it ends up being too slow, you can always refactor it and rewrite the speed critical parts in C++.

However, I'd be happy to see a new driver written in ANY language other than C.  I've done my time in the strdup() trenches and have moved on.

Offline silenus

  • BFF
  • ***
  • Posts: 199
    • View Profile
Re: driver rewrite
« Reply #31 on: July 26, 2008, 02:59:02 am »
There was a discussion of the idea of self-hosting LPC on I3 dchat and the issues involved. The main hurdle is that unless the coding was done in DGD LPC MudOS currently lacks something resembling a parser generator and given that to parse MudOS LPC you require lookahead of k = 3 hand implementing such a parse table would be error prone and a significant chore as well as being sensitive to changes in the grammar if it is modified for whatever reason.

So the first step in such an implementation would be to build a parser generation tool of some sort. MSIL would be an interesting target but given a thin runtime layer is needed i.e. method calls/invokes would have to be wrapped for sandboxing purposes it is difficult for me to see how to easily construct a version which is programmable in any language since the either the compilers would all have to be retooled to include the sandboxing features or the VM would- both tasks are probably nontrivial.

My goals for a possible driver project are somewhat different than Wodan because for me the requirements differ. Introducing small incompatibilities to me isn't really that big a deal as long as I can also construct a porting tool to move the code from MudOS/Fluff LD etc. to the new driver. I think since Wodan may wish to have a plugin replacement for FluffOS for the very large and successful DW mud his requirements are a bit more stringent.

I am of the mind set that in order to garner more interest in programming in LPC that any more driver would have to be modernized to some extent and perhaps modified to be able to cope with a wider range of applications. 

Offline donky

  • Acquaintance
  • *
  • Posts: 35
    • View Profile
Re: driver rewrite
« Reply #32 on: July 28, 2008, 08:45:34 am »
I see scripting languages as being more complicated and unreliable.  Consider the standard LP driver.  It is a binary which provides a programming language and environment.  You don't need to care how it works, only that it does in a stable manner and has for years.  Replace that solid opaque layer with an open one composed of a scripting language, and now the reliability and complication of driver workings becomes the problem of everyone who uses it.

Nope, that doesn't logically follow at all.  The reliability and complication becomes the problem of everyone who MODIFIES it.  Look at the DikuMUD world for a plethora of examples of how drivers, written in C, can be modifed to become unstable and unreliable.

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.

Given this, my argument still logically follows.  But then, maybe we are talking about different things.

My feeling on the public acceptance of applications written in scripting languages, is that they don't have the reputation of quality which binary applications have.

If you had posted that in 1988, I'd have believed you.  But back then you tended to run binary applications on servers via remote connections and glass terminals.  It isn't even really proper to call them "scripting" languages these days, since they aren't used to whip up quick batch scripts.  Do you consider Java to be just a scripting language?  How about Visual Basic or any of the other .NET languages which are used for about 80% of the applications written in the last 5 years?

There is a mine field of topics here which are subjective.  I don't have the time or interest to assert my opinions, experience and so forth on them in forum posts.  By the way, did you know 90% of statistics are made up? :)  But in order to give this point some kind of closure, I will state subjectively, that in my personal use of applications written in the languages you allude to and name, and in the use I have observed by colleagues, I have found them to be second class.  There is no way I can see any conversation we might have on this being resolved here.

Personally, I advocated using .NET because it would bring an LP driver into the "modern era", if you'll pardon my vulgarity.  Adding LPC as a .NET implementation would allow you to then write a driver using any combination of .NET languages you like, wherever they're appropriate.  Yes, you still have to have an LPC interpreter, but that could be coded in LPC itself if that's the desired goal.  If part of it ends up being too slow, you can always refactor it and rewrite the speed critical parts in C++.

However, I'd be happy to see a new driver written in ANY language other than C.

This sounds awful to me :)  Different strokes for different folk.

Offline Kaylus

  • Acquaintance
  • *
  • Posts: 9
    • View Profile
Re: driver rewrite
« Reply #33 on: July 29, 2008, 03:05:21 pm »
Quote
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.

Quote
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 ;-)

Offline Tacitus

  • Acquaintance
  • *
  • Posts: 21
    • View Profile
Re: driver rewrite
« Reply #34 on: July 30, 2008, 09:39:28 am »
Pike also has a built in security system that allows you to have lpmud driver like callbacks for, as an example, I/O. The security system is based on attaching credential objects (Pike.Security.Creds) to objects, programs, arrays, mappings or multisets.

A credential object in essence holds three values:

  • user -- The owner.
  • allow_bits -- Run-time access permissions.
  • data_bits -- Data access permissions.

A quick look shows that it is possible to allow/disallow for indexing, setting of indices, calling of functions, usage of security related functions, changing of active credentials on function call, conditional usage of I/O, and use of destruct.

Offline sarak

  • Acquaintance
  • *
  • Posts: 8
    • View Profile
Re: driver rewrite
« Reply #35 on: August 04, 2008, 09:46:23 am »
<popcorn>
  Watches with great interest
</popcorn>

I'd contribute more but I once considered writing a driver when I once again came to the conclusion that I wanted a driver that could do a little bit of each of the major ones without the different non-technical headaches involved with each.  I don't believe I even got to the equivalent of a hello world program.  Happy to test  ;D

Offline Alexi

  • Acquaintance
  • *
  • Posts: 15
    • View Profile
Re: driver rewrite
« Reply #36 on: August 16, 2008, 10:22:45 am »
Perhaps a bold out of the box suggestion.

LDMud is in transition to a new management team and the lists are showing full orders of magnitude of increase in activity.
Fredick/Hubbe has taken Pike into a new dimension (although not in the direction of mud/gaming).
FluffOS is also showing fresh public resurgence and magnetism that is attracting new and old blood.
Dworkin is ripe to be thoughtfully approached.
Bortas has made huge leaps with .NET and (conceptual) LPC (WheelMUD) although I don't think there is any LIB compatability at this juncture.
Marius->MudOS (no-comment).

There have been some bold suggestions about the future of LPC advanced above... with some natural concerns too.  Why not have an LPC Congress?  It doesn't have to be a big affair (keeping to Crat's concern).

The answer is always no if we don't ask the question.... but for those that might come to the table, just perhaps... there's no harm in exploring the possible.  Particularly if we can pick a quick win, easy victory, common ground upon which to build a 1.0 first 2009 victory upon.

Some things we just know is holy ground, we stay off holy ground... we don't poke bears in cages.

Is now the time the time to try?  Pike, DGD, LDMud, WheelMud, LPMud, LPMoo, ugh... Anyone willing to consider the possibility?

Just a thought...

Alexi

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1022
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: driver rewrite
« Reply #37 on: August 16, 2008, 08:53:03 pm »
I'm a big fan of communication. I'm also a big fan of being open minded, and
inclusive, and all that great stuff.

And I love the idea of a big conference, like the Five Families, coming together
with our bodyguards and flunkies and lieutenants, smoking our cigars
and deciding the fate of the world.

So, I'm with you on the general idea.

The problem I have is that I don't know if the people you've mentioned
all have enough in common that such a meeting would accomplish anything
other than a social event.

I like the idea of a social event, mind you. If that's what yer talking about,
I'm 100% all for it.

But if you mean that there's some kind of matter to be discussed and
decided, I think that:

1) You should be explicit on exactly what that is, and how you think the
decision-making process should go.
2) You should make a separate topic for it, since it would likely deserve it.

-Crat

Offline Holyavenger

  • Friend
  • **
  • Posts: 92
    • View Profile
Re: driver rewrite
« Reply #38 on: December 27, 2010, 06:57:49 pm »
Its too bad we couldnt pool a few dollars and rent-a-coder to just get it done already ::)

Hope that didn't come off as personally hostile toward you...you know me,
"just DO something already" is my big thing.

I just like this idea of a GPL, Fluff-compat driver so much that I
fear seeing it collapse under philosophical blabber before it has
a chance to get out of the starting gate.

I don't mean to try to suppress the discussion of what might be
a better way to do things. I'm just anxious to see the code be born.

-Crat

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1022
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: driver rewrite
« Reply #39 on: December 27, 2010, 07:12:23 pm »
No need. If an OSI compliant driver is the goal, DGD's new GPL status satisfies the requirement.

http://lpmuds.net/forum/index.php?topic=1148.0

Offline Raudhrskal

  • BFF
  • ***
  • Posts: 214
  • The MUD community needs YOUR help!
    • View Profile
Re: driver rewrite
« Reply #40 on: December 28, 2010, 03:38:57 pm »
Keep in mind that "rent a coder" usually ends up with sadness, and that both in case of "few bucks" and "few kajilion bucks" spent. You need to have luck and know the stuff enough to not let the contractor produce a code of the type seen on thedailywtf.com ... you want good stuff, you really have to do it yourself (or with friends).
I think, therefore i may be wrong.
Please note that if you met a Raudhrskal in a place that's not related to muds, it wasn't me. *sigh*... back when I started there was zero hits on google for that name...