Pike is an object oriented, interpreted programming language. It is fast, dynamic, high-level and easy to extend, and is similar in syntax to C++.
Pike is also a fish.

Pike's features include:

• garbage collection,
• advanced string functions,
• 8 years of development behind it,
• advanced data types such as associative arrays,
• support for bignums,
• builtin socket support, and
• lots of modules such as a SQL client, HTTP, GTK, Threads, Images etc.

A comparison is made in the Pike manual:

Python

Python is probably the language that is most like Pike. Pike is faster and has better object orientation. It also has a syntax similar to C++, which makes it more familiar for people who know C++. Python on the other hand, has a lot more libraries available.

C++

Pike's syntax is almost the same as for C++. A huge difference is that Pike is interpreted. This makes the code slower, but reduces compile times to almost nothing. For those few applications which require the speed of C or C++, it is often easier to write a Pike extension than to write the whole thing in C or C++.

Lisp and Scheme

Internally Pike has a lot in common with simple interpreted Lisp and Scheme implementations. They are all stack based, byte-compiled, interpreted languages. Pike is also a 'one-cell' language, just like Scheme.

Pascal

Pike has nothing in common with Pascal.

Tcl/Tk

Pike is similar to Tcl/Tk in intent and they both have good string handling. Pike has better data types and is much faster however. On the other hand Tcl/Tk has X windows system support.

Finally you can look at The Great Computer Language Shootout for the speed of Pike compared to other languages.

RXML stands for Roxen eXtensible Markup Language and is a set of tags, containers and simple programming language constructs that can be placed in HTML source code. These tags and containers will be interpreted by Caudium each time the page is requested. This allows non-programmers such as web designers to develop complex web based applications without having to learn anything more difficult than HTML.

The best way to learn whether Caudium fits your needs is to install it and give it a go! Caudium is a flexible, robust platform that excels at dynamically generating almost any kind of content you can think of, from a variety of sources including SQL databases.

If you need to run a web server on Windows® or on any other platform for which Caudium is not supported. Caudium is actively supported by its developer community on Linux, Solaris®, and most variants of BSD. Caudium should also work on any Unix® flavours for which Pike binaries are available.

Caudium was an ancient city in the Roman Empire (or somewhere nearby). We chose the name because we liked it and it is a rarely used word (also it is not a lake, an Indian tribe, an animal or anything like that). The fact that both caudium.net and caudium.org were free was of course another bonus.
Caudium is pronounced "cow-dee-uhm".

Our goal is to have Caudium operational on any Unix platform that supports dynamic linking and for which Pike is available. Currently, Caudium is actively supported on the following operating systems:

• GNU/Linux (kernel 2.2+. Debian packages have been available since Debian 3.0)
• FreeBSD 4.x (a port is in the official tree and a package is available on the FreeBSD 4.7 CDROMs)
• OpenBSD 2.9 and newer (a port is on the way)
• NetBSD 1.5.2 and newer
• AIX®
• Solaris (2.6, 7, 8 or 9)
• MacOS X® (using Pike 7.2 or later)

It is likely that Caudium runs well on other Unix platforms, however the developer community hasn't yet been able to test Caudium on any other systems, but it is likely that we would support other operating systems given the resources. There will never be any support for Windows, and all legacy support from Roxen Challenger has been actively removed.

Caudium might run on Windows when Pike is compiled with Cygwin. However Pike under Cygwin is not yet supported by the Pike developers and is a bit of a hack.
Otherwise, Caudium will never be supported on Windows.

Yes. Caudium uses a scheme similar to Linux's version number system. Each version of Caudium is numbered with a major, minor and build number in the format a.b.c.
The major version number represents the number of rewrites or signifigant overhauls of the existing codebase.
Developer (or unstable) releases have odd minor version numbers (1.1, 1.3, 2.5 etc) while stable releases are even numbered (1.0, 1.2, 3.6 etc).
The build number is uneven for CVS check out or snapshot versions but even for actual releases.

When a release is near, the codebase is placed in feature freeze and testing for bugs starts. When all obvious bugs have been resolved, the code is frozen and a snapshot is created called release candidate 1, or just RC1. The release candidate is tested thoroughly and only important bugs are fixed (minor problems, like typos, will not be fixed after the code freeze). If major problems are found in RC1 then they will be fixed, and the resulting snapshot will be renamed RC2. This process is repeated until there are no more major problems and the resulting snapshot is officially named the stable release and given even minor and build version numbers (for example 1.2.8).

• Caudium 1.0.xx anything newer than Pike 0.6.116 and all Pike newer than 7.0.190 should work. However, Caudium 1.0.xx branch does not support newer Pikes (eg 7.1, 7.2, 7.3, 7.4...).
• Caudium 1.2.xx all Pikes newer than 7.0.190 and older than 7.3.40 should work. However we strongly recommend that you use a Pike newer than 7.2.192.
• Caudium 1.4.xx branch it designed for Pike 7.6.24 or newer.
• Caudium 1.5.xx branch it designed for Pike 7.6.24 or newer.

I get the following error when trying to compile Pike:

     /precompile.sh precompile.pike >"/usr/local/pike-7.2.432/src/builtin.c" 
     "/usr/local/pike-7.2.432/src/builtin.cmod" || { rm "/usr/local/pike-7.2.432/src/builtin.c"; exit 1; }
     precompile: /usr/local/pike-7.2.432/src/pike -DNOT_INSTALLED  -m/usr/local/pike-7.2.432/src/master.pike \
      ./precompile.pike  /usr/local/pike-7.2.432/src/builtin.cmod (method=Q)
     ./precompile.sh: line 151: /usr/local/pike-7.2.432/src/pike: No such file or directory
   

You are compiling Pike from CVS or from a CVS snapshot. You need an "exported" version of Pike. We provide these for Pike 7.2.

UltraLog is a very fast log parser. The parser is written in C (as a Pike module) and the viewing is done through a Caudium module. The summarizing is done using an external application. Features include, but are not limited to, customizable log format, multiple log files per profile and wild card profiles (in a sense). Future plans include better integration (web based configuration for example).

XSLT is an XML transformation language. It can be used to generate various output formats from an XML input (you can think of it as templates). PiXSL is a glue to the Sablotron XSLT parser. The current state is "working, without intelligent caching". You can use the current implementation by adding the Caudium XSLT Tag module or by using the XSLT Template module, which more or less works like mod_xslt for Apache.

When we have started to make PiXSL there were not too much XSLT parser available in the world. Sablotron was the first stable and usuable in the world. That's why we have choosen this one.
Maybe we will update PiXSL for another parsers than Sablotron, but we are looking for people to update this XSLT Tag module.

This module contains all our custom C-code which is too small to be a self-contained module. Today it includes a query string parser and a HTTP header parser as well as a more complete HTTP request parser used by the http2 protocol.

We are somewhat unhappy with the direction the Roxen development is heading. We believe that the success of Roxen WebServer is being hindered by the commercial needs of Roxen IS. The 2.0 version was initially not very backwards compatible (despite claims that it was). Also it was a lot slower (something that might be fixed in Roxen 2.1) and rather unstable. These things might or might not be fixed by now.

Roxen 1.3 is a dead project. We could not possibly get the necessary freedom to develop the server the way we want (starting at such a simple level as write CVS access). If we had chosen to do this, it would have been "A Patchy Server" all over again (i.e. we would have had to work with patches to the Roxen 1.3 source). Also we want to continue development in new directions instead of just fixing problems.

We believe that they have shown historically shown a lack of respect for the small, but existing, Roxen community. It is our hope that Roxen IS will see Caudium as a challenge and an opportunity to expand the combined Roxen / Caudium communities and also as a way to keep Roxen 1.3 users happy.

Quite a few things have been fixed, tweaked and added since the fork from Roxen 1.3. This includes fixes to long-standing bugs, performance enhancements, Pike 7.x compatibility, availability of both the old RXML parser and a new XML compliant parser, support for scopes and (when using the XML parser) entities, and more. Read the CHANGES file in the top-level caudium directory for more details.
We have also added a number of features that existed prior to the fork like UltraLog (a log parser), PiXSL (XSLT support), CAMAS and more.

Yes, we would like to see it that way; but since we consider it to be a new product, the version numbers start at 1.0.

Many reasons could be listed here. The main one might be that you are a Roxen 1.3 user, and you do not have the resources to rewrite your RXML pages. Also you might not agree the direction Roxen 2.x is heading. It is up to you to make up your mind.

The greatest dislike was the lack of compatibility. According to Roxen IS the 2.1 version should be a lot better in this aspect but we can not confirm or deny that. The speed degradation and lower stability was another big problem. Again, Roxen IS claim to have resolved many of these issues. The new XML parser is a great idea which today comes with a noticeable speed drawback. Caudium now has an optional XML compliant parser which is about half as fast as the old parser. We love the entities since they hugely simplify some things (and we are implementing these into Caudium as well). We also like some, but not all, aspects of the new configuration interface.

The RXML Compatibility Module is not 100% compatible to RXML 1.3 and probably never will be. The compatibility module cannot be used because it is not guaranteed to work. In order to use it it must be guaranteed to work, which can not happen, because for that it must be test. Again this will not happen, because nobody uses it without a guarantee. The only way to achieve compatibility is to start out with something compatible, and then slowly introduce new stuff into that, but not the other way around. We understand that this is not possible with the new RXML parser, therefore the old parser must simply be kept around.

Roxen WebServer needs an open XSLT implementation. XML/XSL/XSLT are important technologies for the future of web sites. Although Roxen IS has said that they will release their XSLT technology free, there is no way knowing then or if this will happen.

Since the announcement of Caudium, Roxen IS now have a working bug tracking system. We applaud the effort but still want to point out that this did not happen until the threat from us.

It has always been hard (or even impossible) to add own code/fixes/features to the source tree. Of course, RIS needs to take care about the integrity of the code, but it is not the origin idea of Open Source development. We should find a way to make it possible for trusted developers to add code to the source tree which could be added to the distributions after reviews.
This is to some extent solved. We do not know how well it works, but in theory external people should be able to contribute to the Roxen WebServer project.

We want a more open development with a better community interaction. Part of this is public plans and ideas, bug tracking etc. We will try to do a better job motivating 3rd party developers and also making people want to work on Caudium itself. Only time can tell what will happen.

Since we went public, RIS has fixed a lot of problems like the bug tracking. We believe this was part of an effort on their side to make Caudium go away (fix all the problems and we have no reason to live, right?). However we will continue to thrive, going in our own direction with our own goals.
We can understand that Roxen IS has a lot of priorities listed in another order and is not able to fulfill all wishes from the user community but the user community cannot wait forever.
Some of us simply want to see Pike gain a larger user base, and don not care whether Roxen or Caudium help that goal. Others just can not switch to RXML 2.0 at this time. Some just like the idea that Caudium has no commercial agenda.
We do think there is a place for both Caudium and Roxen. Our target area, web serving, is a huge market with very fast growth (that Roxen has not been able to keep up with). The existence of Caudium will not affect Roxen negatively.

David Hedbor was the author of the old site with more or less all the material (typos and all), as well as the simple design.
Current design is done by Blackwell and coded by Xavier Beaudouin.

The web site is made using a simple RXML template, included in each file using the <use> tag. The template file has a bunch of custom tags we use. On the client side, it uses HTML, CSS style sheets and the PNG image format.

Yes. We do not have a finished plan for this, yet, but basically the way it will work is that you simply check out the HTML code from the CVS repository on a regular basis. Mirroring using a normal batch downloading tool is not a good idea for obvious reasons. :-)

This is something we will probably eventually do, but right now we do not have time. If you are interested in translating to your language, please let us know.

Please send a mail to the master of the web with details about the error.

The Website is made using CSS{1,2,3} and HTML 4.01, your browser may not be 100% compliant with those standards.

Maybe you should try some recent browsers like Mozilla, Galeon, Netscape 6 or 7, or Microsoft Internet Explorer 6.

A couple of reasons. First of all some of them probably would not be included, like PCRE (it is not "good" enough). Secondly new modules in Pike would only be added to Pike 7.1. Since we plan to use these extension modules in Caudium (optionally of course), we need to support Pike 7.0 as well.

That depends, but probably yes. The requirement is that it works with Pike version 7.0 and up and that it has a working configure script (we supply a simplified setup similar to that of Pike). Send a mail to the general mailing list with details about your module.

No. Due to various API changes (mainly to make the creation of Pike modules easier) in Pike 7, we have decided not to support earlier versions than 7.0. Any module that currently works with 0.6 will probably be rewritten to use new features of Pike 7.0.

Sure, why not? The main purpose of this project is to make it easier to compile C modules, but Pike modules can of course also be added.

It is in our CVS repository. See the download page for details. The module name is pexts instead of caudium. Compilation and installation is basically the same.

Uncertain at this point. One strong possibility is a Berkeley DB module.

Probably. If it happens that would be great and we hope that we can have a good relationship with the Pike authors in that bug corrections get shared. However even if a pexts-module is added to Pike, it will still exist in pexts for the backwards compatibility reasons mentioned above.

That is not our initial plan. However that is not a bad idea. A better plan might be to make an SDK and a central repository allowing anyone to create custom Pike modules without doing to much magic configure/makefile hacking. We will certainly consider this.

GPL. Pike is a GPL program so using any other license (at least any non-compatible one) is not allowed. Of course, we also want it to be possible to integrate our code into Pike, which again requires the license to be GPL.