the Karma System - Advanced Bulletin Board Software.
the Karma System is the single most simplistically complex piece of bulletin board software ever known to humble man.
the power that lies within allows the Operator to not only customize, but to completely and utterly alter the appearance and functionality that is presented to the User. this is because, simply put, Karma is not so much ``Open Source'' as she is ``Liquid Source''. what this means for you is that your bulletin board can become an extension of your body and mind. such as is the case with say, a weapon of mass destruction. the only difference being that, with Karma, there is love to be had.
and remember, what comes around goes around;
..
karma is based on many unix priciples. however, karma duplicates and extends on several services in order to avoid 'taking over' the host system. put more simply; Karma won't grow roots.
the following is a loose list of features for this release:
systems sharing the same bbs are called 'shadows'; logging into any one shadow is indistinguishable from logging into the 'real thing'. think of it as a mirror.
systems belonging to the karma support network are called pods.
individual bbs entities are just called bbs's ;-) bbs's may share certain aspects, such as sig's (special interest groups), file bases, and teleconferences.
karma is very secure!
these types may be combined in any order and contained within a Form.
optionally, an operator can choose the spool type of message base, in which the correspondence will only be stored locally ( but still accessible to shadows ).
see the ktalkd ( karma talk daemon ) documentation for more specific information.
in karma's journal system users in the same group can read each others public diary entries. this is perfect for personal notes, changelog entries, and various things of that nature. in practice, I think we communicate more using this feature than with the post office!
most bbs software ends up creating its own little scripting / layout language anyway, so we at the kdc decided to leave the language development up to Larry Wall and his army of perl lovers, letting us focus on what's important; making an awesome bulletin board.
keep in mind, we've seen the other bbs software out there that is written in perl. although good intentioned, the authors of this software don't seem to grasp the entire scope of what a bbs should provide, and how to apply their knowledge of perl/cgi programming to the bbs paradigm. we hope that they will be inspired by our work just as much as we have been by theirs, and maybe even jump in the pool and contribute to the karma cause!
..
when data is compressed, when ideas are crunched and forced into the time it takes to download 25 lines over a 300bps modem,
the mind is reborn.
suddenly, but not surprisingly, these thoughts take on new shape; a depth that could not be reached any other way.
"into electric attitude, I extrude my world to you". as this dim, green text dances its way across my terminal, I read it and think.. think of all the things that could be so sweet, if only they had the chance.
this world inside the machine seems so perfect; so perfect because it is whatever you wish it to be. sometimes it can even be everything.
most of us grew up in this world. friends, enemies, lovers; they all shared some strange attraction to the unknown, to the dial tone. to the machine that waits on the other end, the one that would do anything to please you, to keep you coming back. it is our wish to share this, forever. in this ever changing world, one thing should stay the same.
there should always be a place for us.
..
we urge one and all Karma operators to join the mailing list. there are always updates, tips, tricks, and bits of vital information within. you can either join privately, or add the list to your Karma archives.
In fact, if you love Karma as much as we do, why not become a developer?
while reading please keep in mind that these were intended to amuse.
as of today there are currently three methods available to store and display text graphics in the Karma System. these are as follows:
as much as I hated to have to include another terminal emulation in the system, it was necessary. curses, you see, lacks any way of expressing rendition changes within a string.. sure you can do it statement by statement, but that doesn't fit with Karma's style of interface. to be honest, nothing about curses fits with Karma.. there comes a time, however, when we must all make our sacrifices.
c strings are very simple; there are very few escape codes. they all begin with a caret (^), witch is then followed by either:
first the cursor is homed with the statement '^{,}', as you can see the zeros may be omitted to save space. bear in mind, that in curses (hence karma) all cursor/ screen locations begin at zero. next, the foreground color is set to 6 (cyan) and the background to 0 (black). currently these colors may only be changed in tandem. finally, with the last escape code '^B' we set the BOLD attribute so that our cyan text will appear quite bright and offensive.
the direct interface to the c string interpretor is through
a function by the name of printc(). just as many other
curses calls, printc()
takes a variable list of arguments:
void printc(*WINDOW win, int y, int x, char* a) void printc(int y, int x, char* a) void printc(*WINDOW win, char* a) void printc(char* a)
a common idiom you will notice in the Karma base code is printc used in place of printf:
printc $window, sprintf(FORMAT, LIST);
I found this to be such a convenient solution as to negate the need for any other type of work-around.
here you will find items such as the users current status, host name of the machine an pid of the karma process owning the node.
small temp files may be kept in the node tree (karma/node/num/tmp), as it is cleared upon every new instance of that node. Keep in mind, however, that on system utilizing karma's Shadow feature this may generate excess NFS traffic; in such cases it is better to use a unique file in /tmp instead.
you'll notice that unlike most other UNIX(tm)
based bbs software,
the Karma System doesn't store user information in /etc/passwd.
there are many reasons behind this, the foremost being Karma's
modular nature; it would be far too invasive to interfere with
the name space that may belong to other services you provide
(ie, ftp, shell, pop). this can be especially usefull if you
to not own the machine that your board is hosted on.
combine that with the fact that Karma doesn't run as the super-
user, and you've got yourself a win/win situation.
this is a key factor in the power of Karma.
[details]
Hidden users have a unix_name() that begins with '.' (period); once a user is hidden by the Operator she will no longer be listed in public settings (such as the node list).
[the following figure is a tree describing karmas user base layout.]
karma/users/ - - user base a user/ - exalted being, may be hidden by prepending a period (.) info - user information rc - initial script for user mail/ - location of personal messages
As some of you close to Karma's development may well know, the project was never intended to be so complex. The goal was to create a lightweight yet capable bbs server in Perl. Well, it turns out that perl has some fundamental problems that make this somewhat difficult. All of this is supposed to change with the release of Perl 6, a completely new language from the people that brought us Perl. This, however, doesn't really simplify things for us now.
Perl 5's shortcomings aren't the only thing at fault, though. The inclusion of Curses in the karma structure was a real turning point in her development. I'm not sure if it was good or bad. Sure, it gives us some flexibility with terminal types, but we pay a large price in speed and simplicity. In the future karma might do away with screen handling libraries all together, or at least make one optional. I think 50% of our work goes tword working around little bugs in terminfo descriptions and curses routines. Sometimes it really doesn't seem worth all of the trouble. There is a bright side, though; Karma has the most advanced terminal support of any bbs software I know.
One might ask ``why not just rewrite the whole thing in C?''.
The answer to that is quite simple: ``That would defeat the entire point!!!!''
There is some talk among the ranks of using Ruby for future version, which does have many of the things that we've been waiting on in Perl 6.