Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Perl Wiki as a System Administrator Tool

News Content management Recommended Books Recommended Links Problems with Wiki Social Problems in Enterprise Unix Administration Slightly Skeptical View on Enterprise Unix Administration
Solaris vs. Linux bread crumbs Kwiki UseModWiki TWiki Scoop DoxWiki
Blogs MediaWiki (now in PHP) Information is not knowledge Wikipedia and the problem of vandalism Humor  Random Findings  Etc

Introduction

Three  important and overlapping aspects of system administration are often overlooked:

Systematizing your own knowledge

As Wikipedia had shown wiki-format allows systematizing vast amount of knowledge in relatively assessable form. Generally hyperlinked text is a very good tool for systematizing knowledge and the first implementations of hypertext were designed specifically for that purpose.

Modern operating systems are an extremely complex maze of complex subsystems and obscure features remembering which is impossible. That means that you always are in situation of elephant and the blind. Some tools are not used often and all information about them is forgotten from one use to another.

For a typical sysadmin that create situations which despite the fact the problem which he/she already  resolved in the past should be treated as new -- as all knowledge about details of the resolution are lost.  For example, if a similar situation happened a year ago or two years. In such case you typically remember nothing about how you approached the problem and how you solved it. That's a very frustrating situation.

Vendor web sites and technical knowledge bases sometimes help, but good, adequate for given situation materials,  are often very difficult to find. Sometimes they are buried somewhere were even vendor web site search engine can't find them.  Sometimes they changed the title. In any case situation when you can't find on vendor site valuable document even if you know that it exist, are pretty common. And search requires a lot of time, sometimes hours, that are essentially lost.  If you have a recorded link from previous time stared on some web page, all those efforts are unnecessary. 

Typical way of systematizing such knowledge via help desk ticket system suffers from several shortcomings. First of all, all known to me corporate helpdesk systems are junk. It is difficult to work with them and that kills any desire to use them for systemizing knowledge. And secondly bureaucratic perversions that are typical in large enterprise helpdesk system implementation make it passionate object of hate. This is a natural feeling when you are forced to so something unnecessary or even stupid day after day. One example are so called "automatically generated tickets". 

That means that creation of your own knowledge base is of paramount importance. You can start with write-up of solved tickets and gradually expand and hyperlink it on a simple web site. So at the beginning you don't need jut Apache and html editor. In no way you need some complex engine to run it. You need some time to see what are your requirements, and then select wisely. Interlinked html pages made from saved emails and helpdesk tickets and edited with HTML editor, for example Frontpage scale to, say,   thousand pages.  That means that this simple format will be adequate for at least a couple of years. But as the amount of pages in your knowledgebase grows you eventually need versioning, some way to search this database, maintain the list of most recent entries, the list of most often assessed entries and other helpers. 

This is functionality that almost any wiki-engine can provide for you. Some store pages in version control system such as Subversion. So in some point you it's better to convert your information stored in "ad hoc" format into wiki. Loading this information is not wasted effort but very important learning activity. Just systematic browsing through your old record open a wealth of forgotten but extremely useful information for you. In a very deep way changing database format and reloading your knowledge database in a new format is a very constructive and useful activity. This is time well spend.

But even more important then the selection of the engine is scheduling fair amount of time for recording and reviewing your activities and experience. That is especially important if you need to support two of more flavors of Unix. In this case you typically forget almost everything from one encounter with the problem to another on less used OS; your records is that only way to stay sane in this environment.   I have had a  pretty painful experience of supporting Linux and Solaris simultaneously at one point of my career.  At the beginning I hated Linux and as I learned more about Linux and forgot most what I learned about Solaris my feelings reversed ;-). Actually attachment to the best known OS in sysadmins has very strong emotional component (love-hate). And I now understand perfectly well those Linux sysadmin that passionately hate Solaris as well as those Solaris sysadmins who passionately hate Linux. Two systems of this level of complexity are  just too much for a single human being and hate is just a manifestation of frustration with experience of a lesser known OS in complex enterprise environment. See Solaris vs. Linux for details.

And if you understand that Linux in enterprise environment has split personality (RHEL and SLES) very soon you will hate your job as in no way sysadmin can be comfortable supporting three complex OS. Even two close OS such as RHEL and SLES are a huge challenge. Unless you find a constructive way to deal this this superhuman level of complexity. And I think creating your own knowledge base is the only constructive way to lessen this tremendous level of frustration with excessively complex environment in which Unix sysadmins needs to survive. And not only solve challenging problems, but solve then quickly.  

Here is what Sandra Stocker wrote about this problem in her IT World article (7 habits of highly successful Unix admins, April 05, 2014)

...If you do figure out why something broke, not just what happened, it's a good idea to keep some kind of record that you or someone else can find if the same thing happens months or years from now. As much as I'd like to learn from the problems I have run into over the years, I have too many times found myself facing a problem and saying "I've seen this before ..." and yet not remembered the cause or what I had done to resolve the problem. Keeping good notes and putting them in a reliable place can save you hours of time somewhere down the line.

... ... ...

In general, Unix admins don't like to document the things that they do, but some things really warrant the time and effort. I have built some complicated tools and enough of them that, without some good notes, I would have to retrace my steps just to remember how one of these processes works. ...In fact, I sometimes have to stop and ask myself "wait a minute; how does this one work?" Some of the best documentation that I have prepared for myself outlines the processes and where each piece is run, displays data samples at each stage in the process and includes details of how and when each process runs.

Keeping user and colleagues informed

One of the most common and the most devastating in consequences problem of large companies (and any large bureaucracies) is that left hand does not know what right hand is doing.

Most users like to know when there is a new functionality available, or when the resources are down or not available. Such content be maintained corroboratively, and added/corrected by users not only by you and other sysadmins. This helps if not in eliminating, but at least lessening the "Kremlin tower syndrome" of over-centralized, outdated and insufficient Intranet content for users,  typical for corporate Web sites.  E-mail communication has a deficiency that after email is read it is forgotten. Also sometimes it is not read at all. While web-based email client is useful and some standalone client like Thunderbird are powerful, systematization of information is difficult using e-mail.  It can and should be used and I find email to be a better tool of informing myself and users about changes then helpdesk engines, but eventually converting them to Wiki pages is a better way to systematize knowledge.

What is important is that such wiki should be developed collaboratively with the users. Just giving users the ability to participate lessen the frustration with the environment. 

Not only such "information portal" makes other administrators and users happier because they are better informed and not just "lurking in a dark".  It also prevents unnecessary helpdesk tickets, which makes your life as a sysadmin easier as well.

That means that efforts in creating such local information portal can pay off rather quickly.

Integration of blog capabilities into wiki

There is a growing trend to combine wiki technology with blogging capability to provide better collaboration and communication solutions.   SocialText and Wetpaint are two example in this direction. In addition, several of the existing content managing systems are beginning to add wiki and blog functions to their product roadmap. 

Pure wiki functionality is not enough and you need at least two additional functions: 

Another approach was described at WikiBlogIntegration:

Blogs and Wikis can be integrated easily if:

I appear to have gotten this to work with B2 and MoinMoin. But I had to hack MoinMoin quite a bit to get the mail in a reasonable format whereby I'd actually want it blogged.

I now also have a hack to B2 that automatically inserts links to wiki pages (with wiki names) that exist, but only if not in between angle brackets - I don't want to have links inside of links as nested anchors haven't been allowed for a long time in HTML land.

HTML vs. WikiWiki markup language

Typically wiki use simplified, very primitive markup language with the implicit (and wrong) assumption that HTML is too difficult.  Although this is a peripheral issue a lot of coding efforts are sunk into reinventing the bicycle.  At some point the wikiwiki markup language becomes a problem rather then solution, as outside very simple cases it is neither simple not transparent. That's actually a real problem with Wikipedia which had outgrown its humble beginnings and have has have wikiwiki as a legacy that created problems rather then being a solution to the problems. Wikipedia might be considered as a case where wikiwiki gradually became  worse then HTML  as substantial financial resources of Wikipedia foundation definitely allow it to improve and extend any high quality HTML open source editor (for example Netscape HTML editor).  There is plug-in that translates MediaWiki wikiwiki format into XHTML (perl-XHTML-MediaWiki )

Some wikis have HTML metatag, so they can accept raw html. Wiki which have those capabilities are preferable to those which do not. Some have capability to export the page in pure HTML. This is another useful extension that has a real value.  

 At some point the wikiwiki markup language becomes a problem rather then solution, so wiki that accept html are preferable to those which do not (it is possible to convert to wiki formatting language from HTML with some loss of formatting).  That's actually a real problem with Wikipedia.

It's better if wiki stores content as regular UNIX files, rather than in a database

While usage of the database can help in implementation of such things as tags, generally it is more important to be able to process files using regular Unix tools without the necessity of extracting content from the database and then putting it back.

Database (and not necessary relational one) should contain only metadata (we should learn something from NSA, should not we ;-)

Vandalism and gradual deterioration of quality

The balance of author control/democracy in wikis is slated toward democracy and thus has some negative side effects like vandalism and "lowest common denominator" problem. 

The "lowest common denominator" problem is related to observable deterioration of initial high quality that some pages used to have, but which later were destroyed by enthusiastic but clueless followers with strong opinions. This problem of deterioration of pages quality with time is clearly visible is Wikipedia, but might be negligent in small wiki with limited audience. It is much less of a problem with internal informational portals. 

In Wikipedia those two effects in certain cases it led to such a serious deterioration of quality of certain technical pages that it sometimes called "GreyPedia" or "DummyPedia". It is unclear how to solve it, as less competent members of the community often have strong opinions and can type really fast ;-)

This problem is even more acute in "political" pages. Here Wikipedia "democratic" approach does not work at all. In certain case Wikipedia now is forced to limit registered users which can edit the most controversial pages. Also it is unclear how "three letter agencies" influence the content of such pages. That's why Wikipedia sometimes is called Ciapedia.

Despite this significant (and very difficult to solve) problem , wikis so far this proved to be a workable solution where abuse does not derail most projects.

Review of wiki engines written in Perl

Perl is the most Unix sysadmin friendly language so wiki engines written in it are far superior to any alternative unless you program in Python or PHP.  It is always better to have an engine in which you can make small code changes that to be just a user. In this sense Wikipedia engine written in PHP sucks. It sucks despite providing the best combination of capabilities among free Wiki engines. 

TWiki

There are several open-source wikis with the revision control built-in  available, such as MediaWiki and MoinMoin, but TWiki has its own set of enthusiasts and strong following. This is a GPL product. The current version is 6.0.0.

One tremendous advantage is that it store pages as plain files (under version control) and does not use database.

It is available in the form of virtual machine too. The Web site claims that

It is a Structured Wiki, typically used to run a project development space, a document management system, a knowledge base, or any other groupware tool, on an intranet, extranet or the Internet.

... ... ...

Here is a non- comprehensive list of how TWiki is being used:

Some of TWiki's benefits are:

Installing TWiki is relatively easy, but still needs work. I hope, as the beta progresses, we will see improvements in ease of installation and upgrading along with clearer documentation.

First, you must create the directory where you want to install TWiki, say /var/www/wiki. Next, untar the TWiki distribution in that directory. Then you must make sure that the user with rights to run CGI scripts (usually apache or www-data), owns all of the files and is able to write to all files:

# install -d -o apache /var/www/wiki # cd /var/www/wiki # tar zxf /path/to/TWikiRelease2005x12x17x7873beta.tgz # cp bin/LocalLib.cfg.txt bin/LocalLib.cfg # vi bin/LocalLib.cfg lib/LocalSite.cfg # chown -R apache * # chmod -R u+w * 

Now copy bin/LocalLib.cfg.txt to bin/LocalLib.cfg, and edit it. You need to edit the $twikiLibPath variable to point to the absolute path of your TWiki lib directory, /var/www/wiki/lib in our case. You also must create lib/LocalSite.cfg to reflect your specific site information. Here is a sample of what might go into LocalSite.cfg:

# This is LocalSite.cfg. It contains all the setups for your local # TWiki site. $cfg{DefaultUrlHost} = "http://www.example.com"; $cfg{ScriptUrlPath} = "/wiki/bin"; $cfg{PubUrlPath} = "/wiki/pub"; $cfg{DataDir} = "/var/www/wiki/data"; $cfg{PubDir} = "/var/www/wiki/pub"; $cfg{TemplateDir} = "/var/www/wiki/templates"; $TWiki::cfg{LocalesDir} = '/var/www/wiki/locale';  

Here is a sample section for your Apache configuration file that allows this wiki to run:

 ScriptAlias /wiki/bin/ "/var/www/wiki/bin/" Alias /wiki "/var/www/localhost/wiki" <Directory "/var/www/wiki/bin"> Options +ExecCGI -Indexes SetHandler cgi-script AllowOverride All Allow from all </Directory> <Directory "/var/www/wiki/pub"> Options FollowSymLinks +Includes AllowOverride None Allow from all </Directory> <Directory "/var/www/wiki/data"> deny from all </Directory> <Directory "/var/www/wiki/lib"> deny from all </Directory> <Directory "/var/www/wiki/templates"> deny from all </Directory>
 

TWiki comes with a configure script that you run to set up TWiki. This script is used not only on initial install but also when you want to enable plugins later. At this point, you are ready to configure TWiki, so point your browser to your TWiki configure script, http://www.example.com/wiki/bin/configure.

You might be particularly interested in the Security section, but we will visit this shortly. Until you have registered your first user, you should leave all settings as they are. If the configure script gives any warnings or errors, you should fix those first and re-run the script. Once you click Next, you are prompted to enter a password. This password is used whenever the configure script is run in the future to help ensure no improper access.

Once you have completed the configuration successfully, it is time to enter the wiki. Point your browser to http://www.example.com/wiki/bin/view, and you are presented with the Main web. In the middle of the page is a link for registration. Register yourself as a user. Be sure to provide a valid e-mail address as the software uses it to validate your account. Once you have verified your user account, you need to add yourself to the TWikiAdminGroup. Return to the Main web and click on the Groups link at the left, and then choose the TWikiAdminGroup. Edit this page, and change the GROUP variable to include your new user name:

 Set GROUP = %MAINWEB%.TiLeggett Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup  

The three blank spaces at the beginning of each of those lines are critical.

These two lines add your user to the TWikiAdminGroup and allow only members of the TWikiAdminGroup to modify the group. We are now ready to enable authentication for our wiki, so go back to http://www.example.com/wiki/bin/configure. Several options provided under the Security section are useful. You should make sure the options {UseClientSessions} and {Sessions}{UseIPMatching} are enabled. Also set the {LoginManager} option to TWiki::Client::TemplateLogin and {PasswordManager} to TWiki::Users::HtPasswdUser. If your server supports it, you should set {HtPasswd}{Encoding} to sha1. Save your changes and return to the wiki. If you are not logged in automatically, there is a link at the top left of the page that allows you to do so.

Now that you have authentication working, you may want to tighten down your wiki so that unauthorized people do not turn your documentation repository into an illicit data repository. TWiki has a pretty sophisticated authorization system that is tiered from the site-wide preferences all the way down to a specific topic. Before locking down the Main web, a few more tasks need to be done. Once only certain users can change the Main web, registering new users will fail. That is because part of the user registration process involves creating a topic for that user under the Main web. Dakar has a user, TWikiRegistrationAgent, that is used to do this. From the Main web, use the Jump box at the top left to jump to the WebPreferences topic. Edit the topic to include the following four lines and save your changes:

Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup Set ALLOWWEBRENAME = %MAINWEB%.TWikiAdminGroup Set ALLOWWEBCHANGE = %MAINWEB%.TWikiAdminGroup, -->;%MAINWEB%.TWikiRegistrationAgent  

This allows only members of the TWikiAdminGroup to make changes or rename the Main web or update the Main web's preferences. It also allows the TWikiRegistrationAgent user to create new users' home topics when new users register. I have included a patch that you must apply to lib/TWiki/UI/Register.pm as well. The patch follows, but you can also download the patch from the LJ FTP site (see the on-line Resources):

--- lib/TWiki/UI/Register.pm.orig 2006-01-04 01:34:48.968947681 -0600 +++ lib/TWiki/UI/Register.pm 2006-01-04 01:35:48.999652157 -0600 @@ -828,11 +828,12 @@ my $userName = $data->{remoteUser} || $data->{WikiName}; my $user = $session->{users}->findUser( $userName ); + my $agent = $session->{users}->findUser( $twikiRegistrationAgent ); $text = $session->expandVariablesOnTopicCreation( $text, $user ); $meta->put( 'TOPICPARENT', { 'name' => $TWiki::cfg{UsersTopicName}} ); - $session->{store}->saveTopic($user, $data->{webName}, + $session->{store}->saveTopic($agent, $data->{webName}, $data->{WikiName}, $text, $meta ); return $log; }  

Otherwise, new users' home directories will fail to be created and new user registration will fail. Once you have verified that the Main web is locked down, you should do the same for the TWiki and Sandbox webs.

When you are done configuring TWiki, you should secure the files' permissions:

# find /var/www/wiki/ -type d -exec chmod 0755 {} ';' # find /var/www/wiki/ -type f -exec chmod 0400 {} ';' # find /var/www/wiki/pub/ -type f -exec chmod 0600 {} ';' # find /var/www/wiki/data/ -type f -exec chmod 0600 {} ';' # find /var/www/wiki/lib/LocalSite.cfg -exec chmod 0600 {} ';' # find /var/www/wiki/bin/ -type f -exec chmod 0700 {} ';' # chown -R apache /var/www/wiki/*  
As I mentioned before, TWiki has a plugin system that you can use. Many plugins are available from the TWiki Web site. Be sure the plugins you choose have been updated for Dakar before you use them.

See also

Foswiki

Foswiki is is a fork from TWiki 4.2.3. See Foswiki - Wikipedia, the free encyclopedia

Like TWiki it is written in in Perl 5 (5.8.8 or higher required). It contains powerful WYSIWYG editor which can be used instead of wikiwiki language.  Works with RCS version 5.7 or higher.

Has some interesting features like macros

Creating a Table of Contents %TOC% automatically creates a table of contents based on the headings present in the topic. To exclude ...

DoxWiki

DoxWiki makes it easy for you to get a wiki up and running quickly. When installed on your computer, DoxWiki weighs in at just over 200KB.

The heart of DoxWiki is a a simple Web server that's written in Perl. To get going, all you have to do is start the Web server at the command line; it doesn't seem to like being launched from a desktop shortcut. Then, open the wiki's main page in your browser by typing http://localhost:8080 in the address bar.

Instead of saving content to a database, DoxWiki saves the individual files that make up the wiki on your hard drive. The files are small, so it would take quite a lot of them to put a dent in your drive's capacity.

Creating wiki pages is simple. On the main page (called the Wiki Root), you type a name for the new page in one of the fields, and then click the Go button. From there, you add content.

Unfortunatly DoxWiki uses Wiki markup language 

DoxWiki also has a couple  of useful features: HTML export filter and a search engine.

One aspect of DoxWiki that I don't like is the default look of the pages. They're not ugly, but they're bland. You can add a custom logo to your wiki pages

ikiwiki

ikiwiki is a free, open source wiki application, designed by Joey Hess. It is licensed under the terms of the GNU General Public License, version 2 or later. ikiwiki is written in Perl, although external plugins can be implemented in any language.

One advantage of ikiwiki is that stores its pages in a standard version control system such as Git, Subversion or others.

ikiwiki acrs as wikiformat compiler and supports several lightweight markup languages, including Markdown, Creole, reStructuredText and Textile. It also has Perl POD tranlator so it can use Perl POD format. (perl-Pod-IkiWiki )

In the simplest case, it can function as an off-line static web site generator, but it can use CGI to function as a normal web-interfaced wiki as well.[3] Login via OpenID is supported.

ikiwiki can be used for maintaining a blog, and includes common blogging functionality such as comments and RSS feeds. The installer includes an option to set up a simple blog at install time.[4]

ikiwiki is included in various Linux distributions, including Debian and Ubuntu.[3]

Use as a (possibly-distributed) bug tracker[edit]

Although wikis and bug tracking systems are conventionally viewed as distinct types of software, Ikiwiki can also be used as a (possibly-distributed) bug tracking system; however, "Ikiwiki has little structured data except for page filenames and tags," so its query functionality is not as advanced or as user-friendly as some other, centralised bug trackers such as Bugzilla.[5]

See also[edit]


Portal icon Free software portal
##Website Meta Language
##Gitit: Another wiki which uses a version control system to store pages
 

Abandonware

UseModWiki

UseModWiki is a Wiki engine written in Perl. Wikipedia used this first before re-implementing their current engine (From January 15, 2001 until early 2002). Other large sites also use UseModWiki.

UseModWiki is very simple to set up and upgrade. It has a rich syntax, and allows for arbitrary characters in page names. It also supports using some HTML tags instead of the WikiWiki markup. It has other nice features, including search, a list of recent changes, and page history.

For simple Perl-written Wikis, UseModWiki is a good choice. Codebase is not that complex and you can implement your own changes.  

Kwiki

The Kwiki motto is a "A Quickie Wiki that's not Tricky." this is an abandonware without a website.  http://www.kwiki.org/ is semi-dead. Download page works. Index of -downloads Installing it is pretty straightforward for a site you admin: just install the Perl package (from CPAN or elsewhere), and then type kwiki-install in a CGI-served directory to create an instance. Installing Kwiki on a server you are not an admin of is more complicated but doable.

I found the Kwiki markup not powerful. Some things are impossible with it, such as hyperlinking an arbitrary piece of text to an email address (mail fooish). I also could not find how to link a Wiki page with a text link different from the Wiki page name (like this link to LinkedWikiWikiPage). There is also no support for attachments, HTML markup as an alternative to the Wiki markup, etc. It is disappointing.

Kwiki can use either RCS or Subversion for version control. Those who wish to use Subversion should check out the corrected Kwiki version as the CPAN Kwiki does not work with the up-to-date Subversion.) Kwiki is easily customizable and has several Kwiki enhancements available.

Generally, however, Kwiki is less powerful than TWiki.

WebKNotes

WebKNotes was an attempt to create a personal knowledge base. It's an old project that lasted probably till 2002. Now it is open source abandonware.  Here is the history:

This whole thing started because I wanted to store information in directories
as plain text and have something that made it accessible via WWW.

At first I made a simple Makefile, that looked at the extension and printed out
an HTML fragment based on the extension. "file2htmlf.mk"
Then I wrote a shell script, "dir2html.sh" that ran the makefile on every
file in the dir and wrapped and HTML title and header on it, the outputting
html went in '.index.html'.

Then dirs2html.sh recursivly called dir2html and put .index.html in ever
directory.

This was slow to use make, so I abandanded it and just wrote dir2html.csh,
that did a 'foreach' and switch.
Faster, but csh is slow too.
So next, it was dir2html.sh.

Next I turned the thing into a CGI script and generated HTML on the fly, 
for a directory passed to it.

At some point, I renamed it to 'notes2html' since was it really was a way
of accessing my notes about things, and not dirs in general.

When I put the thing on my web page, I realized that I needed a better 
way to control writes and to have the write suid, since CGI scripts run as
WWW, or nobody. 'doncreate' then later 'faccess'. 'faccess' was a C program
that restrited types of writes to directories, based on a faccess.conf file.
I used it to write logs, counters, as well as notes. 'faccess' was made to
be an suid Exec. This was now a very secure system, and I owned all the files
that came in.

Once the notes database had a few things in it, it was impossible to find
things in it (at least for an outsider). A search mechanism was needed badly.
At first, I wrote some ugly script that used 'find' and 'grep'. 
This was slow. I needed something that did them both. I didnt want to write
C code either, because that is something to recompile.

I found a search utility written in perl, for searching HTML trees.
Much hacking later, it work for notes2html.

Now I had this cool searchable knowledge database system and needed a name.
Knowledge Notes - KNOTES.

later I converted all of notes2html to perl .. notes2html.pl
Also, I added more perl scripts to subscribe/unscribe via email.

Got rid of use of faccess, as I was running through cgiwrap.

Then I cleaned it all up, modularized it a little, made all sysstem 
dependent defines in one knotes-define.pl file.

Then I finally put documentation with the thing.

1998, rewrote search script, made all the scripts work as setuid scripts.

----
Update 1999, January 13:

License is the Artistic License.
Renamed To WebKNotes, so as not to be confused with KDE's Knotes.

Summary

In essence Wiki is a poor man content management system and most small content management systems can be used along with classic content management system. It is especially effective in creating user-oriented documentation and informing users about status of the systems. See Comparison of content management systems - Wikipedia, the free encyclopedia

Wiki engines that are written in Perl and that use Unix file system for stroring content and allow usage of Html are preferable.

Despite the fact that it written in PHP. Wikipedia engine (Media Wiki) is good enough for the purpose discussed and can be recommended. As an added bonus you (and your users) learn the ropes which gives you possibility to contribute to Wikipedia, which despite all junk it contains and the problems of vandalism and the lowest common denominator is a useful, open tool, that we all should support.

TWiki and DoxWiki are two maintained Perl implementations. Both are big., complex software projects.

Most small modifiable by "regular folks" Perl Wiki projects are abandonware and you can re-use them only if you are ready to spend time learning the codebase and adapting it to your need. Throwing out wikiwiki markup and switching to HTML is a first recommended step. 


Top updates

Bulletin Latest Past week Past month
Google Search


NEWS CONTENTS

Old News ;-)

Wiki Engine Popularity

The following GoogleSearch hit count result list may give insight into the popularity and spread of the various WikiWikiClones.

Although the raw search result numbers may not be an absolute measure of popularity, they can be used to rank relative popularity. The list is cut off at around 50 entries and some frivoulous entries (InternetExplorer, WikiWord, ...) were removed (maybe I've cut out some real WikiEngines as well).


Also see TopTenWikiEngines for a short list of the best WikiEngines based on more subjective opinions.
Another survey done for the WikiCreole workshop at WikiSym August 14, 2006: http://www.wikicreole.org/wiki/WikiPopularity
For comparison, Google yields 12,700,000 for "wiki" and 359,000 for "wikiwiki". Unknown how many of those are purely use of the Hawaiian word.
MediaWiki
76,900000 (2008.7.25)
TWiki (TwikiClone)
4,410,000 (2008.7.25)
TikiWiki
4,190,000 (2008.7.25)
PukiWiki
4,180,000 (2009.7.25)
MojoMojo
3,640,000 (2009-01-22)

 

[Jan 30, 2007]  Project details for Salonify

freshmeat.net

Salonify is a Perl script which displays images that you have organized in a directory hierarchy.

The Web user can choose to see photos as thumbnails or in small, medium, or full-size format; rotate the images; modify the captions; move from folder to folder or image to image easily; and customize the layout. The administrator can also take away any of these abilities from the user if they want. By default, the captioning is totally democratic (or wiki-like)--anyone visiting your site can change the captions. You can also lock this down. Salonify generates nearly w3c-compliant HTML (getting closer all the time) and renders quite well in all tested browsers, including w3m-img, lynx, Mozilla, Opera, Netscape, Internet Explorer, etc.. It uses JavaScript when available but does not depend on it, and makes special allowances for bugs in certain browsers.

[Aug 31, 2006] Personal wikis Three small, simple alternatives By: Scott Nesbitt

Linux.com

Wikis aren't just great tools for sharing information and collaborating on projects. They also make excellent personal information managers. With a personal wiki, all of your to-do lists, notes, and appointments are at your fingertips in form that's easy to use and maintain.

The problem with most wikis, such as MediaWiki (the engine that powers Wikipedia) is that they take a lot of effort to set up and maintain. You have to deal with not only the wiki software itself but also the Web server and database that underlie the wiki. All of that is overkill for anyone who wants a wiki for strictly personal use.

But there are several applications available to someone who wants to get a wiki working quickly as a desktop tool. They don't require much, if any, configuration.

DoxWiki

DoxWiki makes it easy for you to get a wiki up and running quickly. When installed on your computer, DoxWiki weighs in at just over 200KB.

The heart of DoxWiki is a a simple Web server that's written in Perl. To get going, all you have to do is start the Web server at the command line; it doesn't seem to like being launched from a desktop shortcut. Then, open the wiki's main page in your browser by typing http://localhost:8080 in the address bar.

Instead of saving content to a database, DoxWiki saves the individual files that make up the wiki on your hard drive. The files are small, so it would take quite a lot of them to put a dent in your drive's capacity.

Creating wiki pages is simple. On the main page (called the Wiki Root), you type a name for the new page in one of the fields, and then click the Go button. From there, you add content.

Wikis use a markup language based on common keyboard symbols that format text, links (both to other wiki pages and Web sites), and elements on a page. If you don't know wiki markup, DoxWiki doesn't leave you hanging. It comes with a lengthy guide to the markup and how to use it.

DoxWiki also has a couple of other useful features: a nifty export filter and a search engine.

One aspect of DoxWiki that I don't like is the default look of the pages. They're not ugly, but they're bland. While you can add a custom logo to your wiki pages (mine's a frog), I couldn't figure out how to modify the look and feel of the wiki pages.

Going small and simple

If you need a portable and easy-to-use wiki, then you can't get any simpler than Wiki on a Stick and TiddlyWiki. Both Wiki on a Stick and TiddlyWiki are designed to be used on your desktop or to be carried on a USB thumb drive. They're simply HTML files that use CSS and JavaScript to provide formatting and the ability to add pages to your wiki. Well, you're not exactly adding pages as you would in a traditional wiki. Instead, the new content is just appended to the HTML file, and hidden until you click the link to jump to the content.

According to its developer, Wiki on a Stick "can be used as a personal notepad, calendar, repository for software documentation, and many other things." The beauty of Wiki on a Stick is that it is simple. The interface is uncluttered, almost bland. It consists of a heading, a navigation menu, an area for text, and a set of icons. You can easily create and edit pages by clicking one of the icons. When a new version of Wiki on a Stick comes out, you can quickly import the contents of your current wiki to the new version.

Adding and editing content is a breeze. Wiki on a Stick supports a variant of the standard wiki markup -- for example, you enter a + instead of a * to create a bullet. Whenever you edit content, a list of the supported markup appears at the bottom of the page. If you've never used a wiki before, then it might take a bit of time to adapt. If not, then you shouldn't have any trouble learning the formatting codes.

You can edit a Wiki on a Stick with Firefox, Mozilla, and Internet Explorer. While you can browse a Wiki on a Stick with Opera, you won't be able to edit it. Using Konqueror is out of the question, unfortunately. You can also edit the CSS from within the wiki to change its look and feel. If you plan to put the wiki on the Web as a static page, you can configure it so that the edit icon is hidden.

TiddlyWiki

TiddlyWiki is flashier than Wiki on a Stick. It follows the same principles as that application, but does so with a little more pizazz. For example, when you click a link to jump to some wiki content, an in-your-face JavaScript transition brings that content to the top of the page. You can turn that animation off if it bugs you. TiddlyWiki also has a simple built-in search engine that does the job.

TiddlyWiki divides content into two types: Tiddlers and Journals. Tiddlers are general wiki entries -- ideas, notes, to-do lists, or whatever else you want them to be. Journals, on the other hand, are notes that are specific to a day. While I was experimenting with TiddlyWiki, I used Journals to track specific tasks that I needed to do on a particular day, and used one as a personal diary.

You can configure several options in TiddlyWiki. You can set it up to do automatic saves and to create backups. You can also enable regular expression and case-sensitive searches, as well as generate an RSS feed. The latter is useful if you plan to post your TiddlyWiki on the Web. Unlike Wiki on a Stick, though, you can't change the look and feel of TiddlyWiki from the interface. You either have to edit the TiddlyWiki code, or create some sort of custom theme. The TiddlyWiki Web site leads you through that process.

TiddlyWiki has spawned a number of variants. These include GTD TiddlyWiki (aimed at those who follow the Getting Things Done method of personal productivity) and QwikWeb (which is meant to be deployed on a Web site). So, if TiddlyWiki doesn't quite suit your needs, you might be able to find a variant that does.

Unlike Wiki on a Stick, you can view a TiddlyWiki with just about any desktop Web browser, and on the Nokia 770 Internet Tablet. You can edit the content of a TiddlyWiki on a wider range of browser than that supported by Wiki on a Stick: Firefox, Internet Explorer, Safari, and Camino among them. On top of that, you can extend TiddlyWiki with several plugins. See the TiddlyWiki Web site for more information.

Conclusion

Wikis are great tools for capturing and sharing personal information. For personal use, you don't need to worry about maintaining a Web server or database. You can start using these personal wikis almost immediately, without getting your hands dirty configuring and maintaining the supporting software.

In Defense of Wiki Markup

They re-invented the bicycle and did it badly. Compare with Why Doesnt Wiki Do Html Most objections are completely bogus...
March 19, 2004 | The Fishbowl

I found this scathing denunciation of wiki-markup via Mark Pilgrims’ b-links.

Seeing as I’ve spent the last few months writing a product that uses Wiki markup as its basis, I thought I might come to the markup’s defense.

Thanks to a worldwide effort that could have built the Great Wall of China at least once over, there is a single system for text markup [HTML + XML] that is regular, full-featured, and mature.

Micro Persuasion eBay to Launch Blogs, Wikis and Search Tags

Auction giant eBay is preparing to integrate blog and wiki publishing tools into its selling platform, according to a report on Auctionbytes. eBay Blogs will enable sellers to more efficiently market their products. eBay Wikis meanwhile collect fact-based articles written and maintained by eBay Community members. Both tools will be launched at the eBay Live conference in Las Vegas June 13 - 15.

Working off the Auctionbytes story, I dug a little deeper and found more details including a tag/search platform. The eBay Blog help pages here and the wiki information pages here. In addition, as you can see from the screenshot below and the links on the help pages, Skype integration is coming soon too.

WikiBlogIntegration - AndrewSW Pages One simple way of integrating wikis and blogs

Blogs and Wikis can be integrated easily if:

I appear to have gotten this to work with B2 and MoinMoin. But I had to hack MoinMoin quite a bit to get the mail in a reasonable format whereby I'd actually want it blogged.

I now also have a hack to B2 that automatically inserts links to wiki pages (with wiki names) that exist, but only if not in between angle brackets - I don't want to have links inside of links as nested anchors haven't been allowed for a long time in HTML land.

WikyBlog - A Wiki - Blog Hybrid

wikis-the-insiders-guide

Wiki Wednesdays
SocialText picked up and implemented the idea of Wiki Wednesdays.  On the first Wednesday of each month there is usually a meeting held in a few locations in the USA and Canada, and one or two locations in Europe.  People interested in the wiki technology and approach get together to share their experiences and ideas, or make contacts to get help from the experts. You can find out about the latest and recent events here.

Using Wikis and Blogs to Ease Administration By Ti Leggett

2006-02-27 | Linux Journal

This tutorial on TWiki and WordPress shows how wikis and blogs can be useful for system administration and documentation. System administration can be like sailing a ship. You must keep your engines running smoothly, keep your crew and the harbors notified and up to date and also maintain your Captain's log. You must keep your eye on the horizon for what is coming next. Two technologies have emerged over the past few years that could help keep you on course, wikis and blogs.

Maintaining Good Documentation

I find that one of the most difficult aspects of system administration is keeping documentation accurate and up to date. Documenting how you fixed a pesky problem today will help you remember how to fix it months later when it occurs again. If you ever have worked with others, you realize how critical good documentation is. Even if you are the only system administrator, you still will reap the benefits of good documentation, even more so if another sysadmin is ever brought on board.

Some goals of a good documentation system should be:

Unfortunately, keeping your documentation up to date can be a full-time job in itself. Documenting, though not a very glamorous task, certainly will pay off in the long run.

Why a Wiki?

This is where a wiki comes in. From Wikipedia: "a wiki is a type of Web site that allows users to add and edit content and is especially suited for constructive collaborative authoring."

What this means is a wiki allows you to keep and edit your documentation in a central location. You can access and edit that documentation regardless of the platform you are using. All you need is a Web browser. Some wikis have the ability to keep track of each revision of a changed document, so you can revert to a previous version if some errant changes are made to a document. The only obstacle a new user must overcome is learning the particular markup language of your wiki, and sometimes even this is not completely necessary.

One of a wiki's features is also one of its drawbacks. Wikis are pretty free flowing, and although this allows you to concentrate on getting the documentation written quickly, it can make organization of your wiki rapidly spiral out of control. Thought needs to be put into how the wiki is organized, so that topics do not get stranded or lost. I have found that making the front page a table of contents of all the topics is very handy. However you decide to organize your wiki, make sure it is well understood by everyone else. In fact, a good first document might be the policy describing the organization of the wiki! 

TWiki

There are several open-source wikis available, such as MediaWiki and MoinMoin, each with its own philosophy on markup and layout, but here we concentrate on TWiki. Some of TWiki's benefits are:

The most current stable release at this time is Cairo, or TWiki20040904. It was released, as the name suggests, on September 4, 2004, and it has been proven to be very stable. However, it does lack some of the features of the current beta release, Dakar, that I find to be very useful. The Dakar release we use here is TWikiRelease2005x12x17x7873beta.

Installing TWiki is relatively easy, but still needs work. I hope, as the beta progresses, we will see improvements in ease of installation and upgrading along with clearer documentation.

First, you must create the directory where you want to install TWiki, say /var/www/wiki. Next, untar the TWiki distribution in that directory. Then you must make sure that the user with rights to run CGI scripts (usually apache or www-data), owns all of the files and is able to write to all files:

# install -d -o apache /var/www/wiki # cd /var/www/wiki # tar zxf /path/to/TWikiRelease2005x12x17x7873beta.tgz # cp bin/LocalLib.cfg.txt bin/LocalLib.cfg # vi bin/LocalLib.cfg lib/LocalSite.cfg # chown -R apache * # chmod -R u+w * 

Now copy bin/LocalLib.cfg.txt to bin/LocalLib.cfg, and edit it. You need to edit the $twikiLibPath variable to point to the absolute path of your TWiki lib directory, /var/www/wiki/lib in our case. You also must create lib/LocalSite.cfg to reflect your specific site information. Here is a sample of what might go into LocalSite.cfg:

# This is LocalSite.cfg. It contains all the setups for your local # TWiki site. $cfg{DefaultUrlHost} = "http://www.example.com"; $cfg{ScriptUrlPath} = "/wiki/bin"; $cfg{PubUrlPath} = "/wiki/pub"; $cfg{DataDir} = "/var/www/wiki/data"; $cfg{PubDir} = "/var/www/wiki/pub"; $cfg{TemplateDir} = "/var/www/wiki/templates"; $TWiki::cfg{LocalesDir} = '/var/www/wiki/locale';  

Here is a sample section for your Apache configuration file that allows this wiki to run:

 ScriptAlias /wiki/bin/ "/var/www/wiki/bin/" Alias /wiki "/var/www/localhost/wiki" <Directory "/var/www/wiki/bin"> Options +ExecCGI -Indexes SetHandler cgi-script AllowOverride All Allow from all </Directory> <Directory "/var/www/wiki/pub"> Options FollowSymLinks +Includes AllowOverride None Allow from all </Directory> <Directory "/var/www/wiki/data"> deny from all </Directory> <Directory "/var/www/wiki/lib"> deny from all </Directory> <Directory "/var/www/wiki/templates"> deny from all </Directory>
 

TWiki comes with a configure script that you run to set up TWiki. This script is used not only on initial install but also when you want to enable plugins later. At this point, you are ready to configure TWiki, so point your browser to your TWiki configure script, http://www.example.com/wiki/bin/configure. You might be particularly interested in the Security section, but we will visit this shortly. Until you have registered your first user, you should leave all settings as they are. If the configure script gives any warnings or errors, you should fix those first and re-run the script. Once you click Next, you are prompted to enter a password. This password is used whenever the configure script is run in the future to help ensure no improper access.

Once you have completed the configuration successfully, it is time to enter the wiki. Point your browser to http://www.example.com/wiki/bin/view, and you are presented with the Main web. In the middle of the page is a link for registration. Register yourself as a user. Be sure to provide a valid e-mail address as the software uses it to validate your account. Once you have verified your user account, you need to add yourself to the TWikiAdminGroup. Return to the Main web and click on the Groups link at the left, and then choose the TWikiAdminGroup. Edit this page, and change the GROUP variable to include your new user name:

 Set GROUP = %MAINWEB%.TiLeggett Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup  

The three blank spaces at the beginning of each of those lines are critical.

These two lines add your user to the TWikiAdminGroup and allow only members of the TWikiAdminGroup to modify the group. We are now ready to enable authentication for our wiki, so go back to http://www.example.com/wiki/bin/configure. Several options provided under the Security section are useful. You should make sure the options {UseClientSessions} and {Sessions}{UseIPMatching} are enabled. Also set the {LoginManager} option to TWiki::Client::TemplateLogin and {PasswordManager} to TWiki::Users::HtPasswdUser. If your server supports it, you should set {HtPasswd}{Encoding} to sha1. Save your changes and return to the wiki. If you are not logged in automatically, there is a link at the top left of the page that allows you to do so.

Now that you have authentication working, you may want to tighten down your wiki so that unauthorized people do not turn your documentation repository into an illicit data repository. TWiki has a pretty sophisticated authorization system that is tiered from the site-wide preferences all the way down to a specific topic. Before locking down the Main web, a few more tasks need to be done. Once only certain users can change the Main web, registering new users will fail. That is because part of the user registration process involves creating a topic for that user under the Main web. Dakar has a user, TWikiRegistrationAgent, that is used to do this. From the Main web, use the Jump box at the top left to jump to the WebPreferences topic. Edit the topic to include the following four lines and save your changes:

Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup Set ALLOWWEBRENAME = %MAINWEB%.TWikiAdminGroup Set ALLOWWEBCHANGE = %MAINWEB%.TWikiAdminGroup, -->;%MAINWEB%.TWikiRegistrationAgent  

This allows only members of the TWikiAdminGroup to make changes or rename the Main web or update the Main web's preferences. It also allows the TWikiRegistrationAgent user to create new users' home topics when new users register. I have included a patch that you must apply to lib/TWiki/UI/Register.pm as well. The patch follows, but you can also download the patch from the LJ FTP site (see the on-line Resources):

--- lib/TWiki/UI/Register.pm.orig 2006-01-04 01:34:48.968947681 -0600 +++ lib/TWiki/UI/Register.pm 2006-01-04 01:35:48.999652157 -0600 @@ -828,11 +828,12 @@ my $userName = $data->{remoteUser} || $data->{WikiName}; my $user = $session->{users}->findUser( $userName ); + my $agent = $session->{users}->findUser( $twikiRegistrationAgent ); $text = $session->expandVariablesOnTopicCreation( $text, $user ); $meta->put( 'TOPICPARENT', { 'name' => $TWiki::cfg{UsersTopicName}} ); - $session->{store}->saveTopic($user, $data->{webName}, + $session->{store}->saveTopic($agent, $data->{webName}, $data->{WikiName}, $text, $meta ); return $log; }  

Otherwise, new users' home directories will fail to be created and new user registration will fail. Once you have verified that the Main web is locked down, you should do the same for the TWiki and Sandbox webs.

When you are done configuring TWiki, you should secure the files' permissions:

# find /var/www/wiki/ -type d -exec chmod 0755 {} ';' # find /var/www/wiki/ -type f -exec chmod 0400 {} ';' # find /var/www/wiki/pub/ -type f -exec chmod 0600 {} ';' # find /var/www/wiki/data/ -type f -exec chmod 0600 {} ';' # find /var/www/wiki/lib/LocalSite.cfg -exec chmod 0600 {} ';' # find /var/www/wiki/bin/ -type f -exec chmod 0700 {} ';' # chown -R apache /var/www/wiki/*  
As I mentioned before, TWiki has a plugin system that you can use. Many plugins are available from the TWiki Web site. Be sure the plugins you choose have been updated for Dakar before you use them.
 

Putting MediaWiki to use in an organization

NewsForge

Imagine how useful it would be to have an online knowledge base that can easily be updated created by key people within your organization. That's the promise of a wiki -- a Web application that "allows users to easily add, remove, or otherwise edit all content, very quickly and easily," as Wikipedia, perhaps the best-known wiki, puts it. Why not bring the benefits of a wiki to your organization?

If you're sold on the concept, the first thing you need to do is to pick the software that you're going to use for your wiki. If you want hunt around to find out what's out there, a good place to start is Wikipedia's wiki software wiki. If you say, "I'll use whatever Wikipedia is using," that'll be MediaWiki.

MediaWiki installation is easy -- either follow the instructions on MediaWiki's site or read "The open source wiki behind Wikipedia." Install MediaWiki on a server that can be seen by everyone in your organization. You'll then be able to access it from a Web browser by typing in something like http://servername/wiki.

With a brand new wiki there's absolutely no security or control built into it. Anyone that can access the Web page will be able to add pages, comments, and discussions. We're going to stop that. First add a new user account -- you'll need to be able to log on once you've disabled anonymous access. Next, find the LocalSettings.php file in your wiki directory. Add the following lines:

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgShowIPinHeader = false;

With that done, anyone on the network will be able to view the wiki, but only someone with an account will be able to create or edit pages.

You may also want to enhance the wiki pages by adding PHP functionality. To do this, add a function into the includes/Setup.php file:

function ParsePHPTag($Content)
{
 global $wgOut;
 $wgOut->enableClientCache(false);
 ob_start();
 eval($Content);
 $Result = ob_get_contents();
 ob_end_clean();
  return($Result);
}
$wgParser->setHook('php','ParsePHPTag');

Then, if you want to use PHP in any of your wiki pages, don't use the normal <?PHP ... ?> tags; instead use <PHP> ... </PHP>.

Now you can even access data in a MySQL database by adding code like this to a wiki page:

<PHP>

$db = mysql_connect("localhost", "userid", "userpassword");
mysql_select_db("cstellar",$db);

$result = mysql_query("SELECT COUNT(*) stars FROM chyg85",$db);

printf("Records: %s\n", mysql_result($result,0,"stars"));
</PHP>

In this example, all I'm doing is connecting to a database and counting the number of records in a table. Obviously you'd have to use your own database and user details.

MediaWiki is based on PHP, and so as well as being able to use any PHP functionality within a page, you can actually build your own extensions to MediaWiki. If you're interested in doing that, have a look at MediaWiki's documentation on extending wiki markup.

While you're setting parameters, look at your php.ini file. In php.ini, the line session.gc_maxlifetime sets the length of time (in seconds) that a PHP session is allowed to exist, like this:

session.gc_maxlifetime = 1440

This means that if you're editing the wiki then you must click on the "Save page" button at least once every 24 minutes or risk losing your work. You can increase the time to a value that will suit you better -- say to one hour, or 3600 seconds.

At this point you may be saying, "There's nothing here that I can't do with a text editor, an ordinary Web server, and giving group access to the Web files." True -- so let's see where the wiki comes into its own. Try editing the Main page, save the changes, and then click on the History tab. You'll see that MediaWiki tracks who made all changes and when. You can compare the differences between different versions. In one fell swoop you've got yourself a document management system as well as a potential in-house knowledge base.

"Aha!" I hear you say, "if this is just operating in a browser then how can I do spell check or word counts? What about formating?" If you use Firefox as your browser, you can add Firefox extensions to implement those functions. If you're using Firefox 1.5.x, install Spellbound dev and restart Firefox. When you then try editing one of your wiki pages, you'll find that misspelled words are underlined in red. Right-clicking in any editing areas (text boxes, for example) will allow you to display the spell check front end. Once there then it's just like spell checking in any other application.

It's just as easy to get a word count going, this time use roachfiend.com's Word Count. Again, don't forget to restart Firefox after installing the extension. However, the word count doesn't work within the text editing areas. to get around that problem, click MediaWiki's "Show Preview" button tp see your work displayed as a normal Web page. Now you can then select any area of the text, right-click on it, and you'll see that "Word Count" function is available. Click on it to see the number of words in a message box.

Finally you can install a WYSYWIG HTML editor called Xinha Here! Both the spell check and word count extensions also work in the Xinha window.

With MediaWiki set up, you're ready to create your knowledge base; I can't help you there, it's all up to you. MediaWiki and the Firefox extensions have enhanced the way that I do my day-to-day work, and I'm sure that they can revolutionize the flow of information and knowledge around your organization.

[Jun 21, 2006] Assorted findings:

[Feb 27, 2006] Using Wikis and Blogs to Ease Administration    By Ti Leggett 

2006-02-27 | Linux Journal

This tutorial on TWiki and WordPress shows how wikis and blogs can be useful for system administration and documentation. System administration can be like sailing a ship. You must keep your engines running smoothly, keep your crew and the harbors notified and up to date and also maintain your Captain's log. You must keep your eye on the horizon for what is coming next. Two technologies have emerged over the past few years that could help keep you on course, wikis and blogs.

Maintaining Good Documentation

I find that one of the most difficult aspects of system administration is keeping documentation accurate and up to date. Documenting how you fixed a pesky problem today will help you remember how to fix it months later when it occurs again. If you ever have worked with others, you realize how critical good documentation is. Even if you are the only system administrator, you still will reap the benefits of good documentation, even more so if another sysadmin is ever brought on board.

Some goals of a good documentation system should be:

Unfortunately, keeping your documentation up to date can be a full-time job in itself. Documenting, though not a very glamorous task, certainly will pay off in the long run.

Why a Wiki?

This is where a wiki comes in. From Wikipedia: "a wiki is a type of Web site that allows users to add and edit content and is especially suited for constructive collaborative authoring."

What this means is a wiki allows you to keep and edit your documentation in a central location. You can access and edit that documentation regardless of the platform you are using. All you need is a Web browser. Some wikis have the ability to keep track of each revision of a changed document, so you can revert to a previous version if some errant changes are made to a document. The only obstacle a new user must overcome is learning the particular markup language of your wiki, and sometimes even this is not completely necessary.

One of a wiki's features is also one of its drawbacks. Wikis are pretty free flowing, and although this allows you to concentrate on getting the documentation written quickly, it can make organization of your wiki rapidly spiral out of control. Thought needs to be put into how the wiki is organized, so that topics do not get stranded or lost. I have found that making the front page a table of contents of all the topics is very handy. However you decide to organize your wiki, make sure it is well understood by everyone else. In fact, a good first document might be the policy describing the organization of the wiki!

TWiki

There are several open-source wikis available, such as MediaWiki [see Reuven M. Lerner's article on page 62 for more information on MediaWiki] and MoinMoin, each with its own philosophy on markup and layout, but here we concentrate on TWiki. Some of TWiki's benefits are:

The most current stable release at this time is Cairo, or TWiki20040904. It was released, as the name suggests, on September 4, 2004, and it has been proven to be very stable. However, it does lack some of the features of the current beta release, Dakar, that I find to be very useful. The Dakar release we use here is TWikiRelease2005x12x17x7873beta.

Installing TWiki is relatively easy, but still needs work. I hope, as the beta progresses, we will see improvements in ease of installation and upgrading along with clearer documentation.

First, you must create the directory where you want to install TWiki, say /var/www/wiki. Next, untar the TWiki distribution in that directory. Then you must make sure that the user with rights to run CGI scripts (usually apache or www-data), owns all of the files and is able to write to all files:

# install -d -o apache /var/www/wiki # cd /var/www/wiki # tar zxf /path/to/TWikiRelease2005x12x17x7873beta.tgz # cp bin/LocalLib.cfg.txt bin/LocalLib.cfg # vi bin/LocalLib.cfg lib/LocalSite.cfg # chown -R apache * # chmod -R u+w * 

Now copy bin/LocalLib.cfg.txt to bin/LocalLib.cfg, and edit it. You need to edit the $twikiLibPath variable to point to the absolute path of your TWiki lib directory, /var/www/wiki/lib in our case. You also must create lib/LocalSite.cfg to reflect your specific site information. Here is a sample of what might go into LocalSite.cfg:

# This is LocalSite.cfg. It contains all the setups for your local # TWiki site. $cfg{DefaultUrlHost} = "http://www.example.com"; $cfg{ScriptUrlPath} = "/wiki/bin"; $cfg{PubUrlPath} = "/wiki/pub"; $cfg{DataDir} = "/var/www/wiki/data"; $cfg{PubDir} = "/var/www/wiki/pub"; $cfg{TemplateDir} = "/var/www/wiki/templates"; $TWiki::cfg{LocalesDir} = '/var/www/wiki/locale';  

Here is a sample section for your Apache configuration file that allows this wiki to run:

 ScriptAlias /wiki/bin/ "/var/www/wiki/bin/" Alias /wiki "/var/www/localhost/wiki" <Directory "/var/www/wiki/bin"> Options +ExecCGI -Indexes SetHandler cgi-script AllowOverride All Allow from all </Directory> <Directory "/var/www/wiki/pub"> Options FollowSymLinks +Includes AllowOverride None Allow from all </Directory> <Directory "/var/www/wiki/data"> deny from all </Directory> <Directory "/var/www/wiki/lib"> deny from all </Directory> <Directory "/var/www/wiki/templates"> deny from all </Directory>
 

TWiki comes with a configure script that you run to set up TWiki. This script is used not only on initial install but also when you want to enable plugins later. At this point, you are ready to configure TWiki, so point your browser to your TWiki configure script, http://www.example.com/wiki/bin/configure. You might be particularly interested in the Security section, but we will visit this shortly. Until you have registered your first user, you should leave all settings as they are. If the configure script gives any warnings or errors, you should fix those first and re-run the script. Once you click Next, you are prompted to enter a password. This password is used whenever the configure script is run in the future to help ensure no improper access.

Once you have completed the configuration successfully, it is time to enter the wiki. Point your browser to http://www.example.com/wiki/bin/view, and you are presented with the Main web. In the middle of the page is a link for registration. Register yourself as a user. Be sure to provide a valid e-mail address as the software uses it to validate your account. Once you have verified your user account, you need to add yourself to the TWikiAdminGroup. Return to the Main web and click on the Groups link at the left, and then choose the TWikiAdminGroup. Edit this page, and change the GROUP variable to include your new user name:

 Set GROUP = %MAINWEB%.TiLeggett Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup  

The three blank spaces at the beginning of each of those lines are critical.

These two lines add your user to the TWikiAdminGroup and allow only members of the TWikiAdminGroup to modify the group. We are now ready to enable authentication for our wiki, so go back to http://www.example.com/wiki/bin/configure. Several options provided under the Security section are useful. You should make sure the options {UseClientSessions} and {Sessions}{UseIPMatching} are enabled. Also set the {LoginManager} option to TWiki::Client::TemplateLogin and {PasswordManager} to TWiki::Users::HtPasswdUser. If your server supports it, you should set {HtPasswd}{Encoding} to sha1. Save your changes and return to the wiki. If you are not logged in automatically, there is a link at the top left of the page that allows you to do so.

Now that you have authentication working, you may want to tighten down your wiki so that unauthorized people do not turn your documentation repository into an illicit data repository. TWiki has a pretty sophisticated authorization system that is tiered from the site-wide preferences all the way down to a specific topic. Before locking down the Main web, a few more tasks need to be done. Once only certain users can change the Main web, registering new users will fail. That is because part of the user registration process involves creating a topic for that user under the Main web. Dakar has a user, TWikiRegistrationAgent, that is used to do this. From the Main web, use the Jump box at the top left to jump to the WebPreferences topic. Edit the topic to include the following four lines and save your changes:

Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup Set ALLOWWEBRENAME = %MAINWEB%.TWikiAdminGroup Set ALLOWWEBCHANGE = %MAINWEB%.TWikiAdminGroup, -->;%MAINWEB%.TWikiRegistrationAgent  

This allows only members of the TWikiAdminGroup to make changes or rename the Main web or update the Main web's preferences. It also allows the TWikiRegistrationAgent user to create new users' home topics when new users register. I have included a patch that you must apply to lib/TWiki/UI/Register.pm as well. The patch follows, but you can also download the patch from the LJ FTP site (see the on-line Resources):

--- lib/TWiki/UI/Register.pm.orig 2006-01-04 01:34:48.968947681 -0600 +++ lib/TWiki/UI/Register.pm 2006-01-04 01:35:48.999652157 -0600 @@ -828,11 +828,12 @@ my $userName = $data->{remoteUser} || $data->{WikiName}; my $user = $session->{users}->findUser( $userName ); + my $agent = $session->{users}->findUser( $twikiRegistrationAgent ); $text = $session->expandVariablesOnTopicCreation( $text, $user ); $meta->put( 'TOPICPARENT', { 'name' => $TWiki::cfg{UsersTopicName}} ); - $session->{store}->saveTopic($user, $data->{webName}, + $session->{store}->saveTopic($agent, $data->{webName}, $data->{WikiName}, $text, $meta ); return $log; }  

Otherwise, new users' home directories will fail to be created and new user registration will fail. Once you have verified that the Main web is locked down, you should do the same for the TWiki and Sandbox webs.

When you are done configuring TWiki, you should secure the files' permissions:

# find /var/www/wiki/ -type d -exec chmod 0755 {} ';' # find /var/www/wiki/ -type f -exec chmod 0400 {} ';' # find /var/www/wiki/pub/ -type f -exec chmod 0600 {} ';' # find /var/www/wiki/data/ -type f -exec chmod 0600 {} ';' # find /var/www/wiki/lib/LocalSite.cfg -exec chmod 0600 {} ';' # find /var/www/wiki/bin/ -type f -exec chmod 0700 {} ';' # chown -R apache /var/www/wiki/* As I mentioned before, TWiki has a plugin system that you can use. Many 
							plugins are available from the TWiki Web site. Be 
							sure the plugins you choose have been updated for 
							Dakar before you use them.

Keeping Your Users in the Know

One important aspect of system administration that is sometimes overlooked is keeping users informed. Most users like to know when there is new functionality available or when resources are down or not available. Not only does it make users happier to be kept informed, but it also can make your life easier as well. The last thing you want to do when the central file server is down is reply to users' questions about why they cannot get to their files. If you have trained your users to look at a central location for status of the infrastructure first, all you have to do after notification of a problem is post to this central place that there is a problem. Mailing lists also are good for this, but what if the mail server is down? Some people, for instance your boss or VP of the company, might like to know what the status is of things as they happen. These updates might not be suitable to send out to everyone daily via e-mail. You could create yet another mailing list for these notifications, but you also might consider a blog.

If you are not familiar with a blog, let us refer back to Wikipedia: "a blog is a Web site in which journal entries are posted on a regular basis and displayed in reverse chronological order."

The notion of a blog has been around for centuries in the form of diaries, but blogs recently have had an explosion on the Internet. Many times a blog is started as someone's personal journal or as a way to report news, but blogs can be extremely useful for the sysadmin.

Blogs can help a sysadmin give users an up-to-the-minute status of what they are doing and what the state of the infrastructure is. If you faithfully update your blog, you easily can look back on what you have accomplished so you can make your case for that raise you have been hoping for. It also will help you keep track of what your coworkers are doing. And, with many blog software packages providing RSS feeds, users can subscribe to the blog and be notified when there are new posts.

... ... ...

Wrapping Up

I hope that after this whirlwind tour of wikis and blogs you have come to see how they can be beneficial to help your shop run a smoother ship and provide your users with all the information they might want. Just as there are many different sails to keep your ship sailing, there are many different wiki and blog software packages out there. The right package for you is the one that keeps your users happy and you productive.

Resources for this article: www.linuxjournal.com/article/8832.

Ti Leggett (ti@daleggetts.com) is a full-time system administrator. When he's not working, he might be found playing his Gibson B-25 or doing some home improvements or wood working.

Project details for ReciPants

freshmeat.net

ReciPants is a Web-based recipe manager that supports Postgres, MySQL, and Oracle databases. It features searching, categories, exporting, scaling, emailing recipes, password reminders, secure user cookies, internationalization, and fully customizable templated output.

Which Open Source Wiki Works For You

Nov 4, 2004 | ONLamp.com

Kwiki

The Kwiki motto is a "A Quickie Wiki that's not Tricky." Installing it is pretty straightforward for a site you admin: just install the Perl package (from CPAN or elsewhere), and then type kwiki-install in a CGI-served directory to create an instance. Installing Kwiki on a server you are not an admin of is more complicated but doable.

I found the Kwiki markup not powerful. Some things are impossible with it, such as hyperlinking an arbitrary piece of text to an email address (mail fooish). I also could not find how to link a Wiki page with a text link different from the Wiki page name (like this link to LinkedWikiWikiPage). There is also no support for attachments, HTML markup as an alternative to the Wiki markup, etc. It is disappointing.

Kwiki can use either RCS or Subversion for version control. (Those who wish to use Subversion should check out the corrected Kwiki version as the CPAN Kwiki does not work with the up-to-date Subversion.) Kwiki is easily customizable and has several Kwiki enhancements available. Generally, however, they are less powerful than TWiki's.

All in all, Kwiki is easy to install and customize, but its formatting rules are lacking.

... ... ...

UseModWiki

UseModWiki is a Wiki engine written in Perl. Anecdotally, Wikipedia used this first before re-implementing their current engine. Other sites also use UseModWiki.

UseModWiki is very simple to set up and upgrade. It has a rich syntax, and allows for arbitrary characters in page names. It also supports using some HTML tags instead of the WikiWiki markup. It has other nice features, including search, a list of recent changes, and page history.

For simple Wikis, UseModWiki is a very good choice. I recommend choosing between it and PmWiki based on the feature list of both Wikis.

Recommended Links

Softpanorama Top Visited

Softpanorama Recommended

New findings

 

Format translators (open suse)

List of wiki software - Wikipedia, the free encyclopedia

Random Findings

deplate 0.6a  by tlink

Oct 29th 2004

About: deplate is a tool for converting documents written in an unobtrusive, wiki-like markup to LaTeX, DocBook, HTML, or "HTML slides". It supports embedded LaTeX code, footnotes, citations, bibliographies, automatic generation of an index, etc. In contrast to many wiki engines, it is made for "offline" use as a document preparation tool. In this respect it is similar to tools like aft or txt2tags. It aims to be modular and easily extensible. It is the accompanying converter for the Vim viki plugin.

Changes: Two bugs that prevented it from running on an OS with case-sensitive file names or with the Win32 exe have been fixed. There are minor amendments.

Faq-O-Matic

The Faq-O-Matic is a CGI-based system that automates the process of maintaining a FAQ (or Frequently Asked Questions list). It allows visitors to your FAQ to take part in keeping it up-to-date. A permission system also makes it useful as a help-desk application, bug-tracking database, or documentation system. Jon wrote an article about the FAQ-O-Matic that appeared in the USENIX ;login: newsletter: http://www.usenix.org/publications/login/1998-6/faq.html.

This documentation itself is, naturally, maintained with Faq-O-Matic. Hence the weird title. If you see anything that can use updating, please do fix it! If you just want to play around, check out the

Playground.
 

The Users' Guide tells new users what a FAQ-O-Matic is, how to read it, and how to contribute to it.

The Administrators' Guide tells FAQ administrators how to download, install and maintain a FAQ-O-Matic. If you want to start your own FAQ-O-Matic, look here.

The Playground is a place where anyone can experiment with the FAQ-O-Matic by creating their own answers.

The List Of Faq-O-Matics is a list of websites that use FAQ-O-Matic.

Here are Postcards I have received from people who use FAQ-O-Matic.

This is the Faq-O-Matic Sourceforge page: http://sourceforge.net/projects/faqomatic
lost+found

Jon Howell is a graduate student working with David Kotz at Dartmouth College. His research is on single-system-image operating environments that span administrative domains. He also enjoys robotics, web glue, and kernel tweaking.

What is the best way to maintain a Frequently Asked Questions list? Traditional FAQs are maintained by hand and often become outdated as the maintainer loses interest in the task. Mailing list archives can be helpful, but are often too disorganized. When I found myself answering the same FAQs about Linux for PowerPC and MkLinux last year, I faced this very problem. I am far too lazy to commit to maintaining a FAQ, but the mailing list archives were not significantly reducing the load of redundant questions.

Solution Design

The FAQ-O-Matic is a Web-editable FAQ designed to offer a middle ground. Because the general public can edit it, it is less likely to become neglected and stale like a manually maintained FAQ. Because changes are submitted where the FAQ is read, one can be rather lazy and still contribute to the FAQ. No one person has the responsibility of maintaining the entire document.

Because a FAQ-O-Matic is topically and hierarchically organized, browsing solutions is easier than it is in mailing list archives. Queries on mailing list archives can return matches for old, outdated information and miss newer answers. The topical organization of a FAQ-O-Matic helps avoid this problem as well.

A search function makes FAQ-O-Matic as accessible as a mailing list archive. Another function lists recently changed items, so users can check back for changes if they did not find a satisfying answer the first time they looked. There is a command to show entire categories in one HTML file, to facilitate printing or export of the FAQ.

How It Works in Practice

I launched the first FAQ-O-Matic by seeding it with about 60 or 70 answers gleaned from recent list postings. Although this opposed my laziness philosophy, I knew that I would not be responsible for keeping the answers up to date. Then I began advertising it by answering questions with URLs to the FAQ-O-Matic.

One problem with the initial implementation was that answers were identified by their location in the topic hierarchy. So if you sent out a URL to a FAQ-O-Matic answer and the database was subsequently reorganized, that URL would go sour.

I initially thought allowing people to submit questions without answers would help define the structure of the FAQ by reserving spaces for answers when they became available. Instead, people who were too lazy to search would post poorly considered questions in inappropriate categories.

The submission page asked users to leave an email address with their comment, but people often forgot or inserted text between previous text and its attribution. Furthermore, although the server uses RCS to protect against wholesale vandalism, there was no way to trace subtle, intentional corruption of the database.

The FAQ-O-Matic allowed the entry of HTML tags, so users could supply links and formatting information for their answers. However, other than links, HTML was rarely used to good effect. Instead, it often made for inconsistent appearance as people appended to existing answers and as HTML tags fought with the formatting generated by the CGI script. Furthermore, code segments pasted into the FAQ-O-Matic would mysteriously lose < and & symbols.

Finally, I found that I had to put in a certain amount of effort moving answers around to keep them organized as new answers showed up. This was compounded by the difficulty of performing this sort of administration on the first implementation of FAQ-O-Matic.

Version 2

Over the summer, I rewrote the FAQ-O-Matic to address these problems. First, each answer is now assigned a permanent ID number. This solves the sour URL problem and also provides a facility for "see also" links inside the FAQ.

I posted a policy disallowing questions without answers, which trivially solved the second problem.

The new version has an authentication scheme that verifies email addresses by sending a secret validation code to the given address. Thus each submission is attributed to a real email address, and intentional corruption, once noticed, can be traced and rolled back.

FAQ-O-Matic 2 no longer allows HTML tags; they are displayed as entities (&lt;). This prevents code from becoming corrupted and enforces a uniform (if bland) appearance. Links are supported heuristically by detecting things that look like links (http://...) and generating HTML links on the fly. Internal links are supported with a special URL that begins "faqomatic:"

Version 2 also has support for reorganizing answers and categories from the Web interface. This facility might allow a Web user to moderate a section of the FAQ and care for its organization. Moderators can request that they receive mail whenever any answer in their area is changed, minimizing the effort associated with the moderation task.

The 1998 LinuxPPC CD was announced in January, prompting an estimated 4,500 people to visit the FAQ-O-Matic on <www.dartmouth.edu> in one day. Because every request required service by a Perl CGI, the memory pressure overloaded the server, and the FAQ-O-Matic had to be throttled. In response to that event, version 2.6 adds a server-side HTML cache, so that people who are only reading the FAQ receive HTML directly from the Web server, without the cost of invoking the CGI.

Other Uses

Because FAQ-O-Matic has an authentication scheme, it made sense to give it flexible authorization as well. The FAQ can be configured to be very open, not even requiring mail-back email secrets, to encourage the shy, lazy, or anonymous contributor at the expense of accuracy of attributions.

Alternatively, it can be set to allow only assigned moderators to modify the FAQ. In this arrangement, it is suitable for use as a help desk database: only help desk operators can modify the database, but it is available for all to read.

Numbers

The Linux on PowerPC FAQ-O-Matic has been available for 15 months. In that time, about 75,000 different people (IP addresses) have seen it, and it has received 1,500 submissions. On average, visitors access it about ten times. A few dozen people claim to be running their own FAQ-O-Matics, some for internal projects, others for Internet-accessible sites.

Conclusion

The FAQ-O-Matic has turned out to be a successful system for documenting the Linux on PowerPC projects. It is more organized than a mailing list archive, but avoids going stale as traditional FAQs often do. It allows a division of labor in maintaining both answers and the overall organization of the FAQ. And it has access control features that make it suitable for other applications. To try it out, visit the FAQ-O-Matic at <http://www.dartmouth.edu/cgi-bin/cgiwrap/jonh/faq.pl>.




Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 06, 2014