Thalassa is a CMS written with simplicity in mind. Clearly, there are different points of view on what simplicity actually is; the simplicity provided by Thalassa is best visible from system administrators' and package maintainers' point of view, as its list of external dependencies is reduced to a minimum close to absolute.
Contents:
To build it, you need:
The best news is: that's all. Thalassa doesn't depend on any external libraries, not even the C++ “standard” library; it only uses a (small and obvious) subset of plain C standard library, and all other libs it needs are found within the source tarball. It is written using a very restricted subset of C++ as such — actually, the C++ language as it was before the so-called “standards” turned it into a complete mess (yes, before the very first damn standard known as C++98).
With Thalassa, you will never run into dependency hell; it will never force you into updating, upgrading, renewing or otherwise adapting anything on your computer.
And yes, it does build statically if you want so.
What you need to run a site managed with Thalassa, depends on whether you are going to use its interactive features. If your site is not intended to be interactive, actually you only need a web server software capable of providing access to static HTML files, which effectively means any http server. You don't even have to run Thalassa on the server computer, it is possible to generate your site on your own computer and upload the resulting HTML to the server.
The interactive capabilities of Thalassa currently include user comments and a contact form; if you need these on your site, you will at least need to run Thalassa on the server. Strange enough, this can be problematic, as many of hosting operators that provide 'shared hosting' service don't allow to run binary executables within their web space. Usually they say it's all for the “security”, but that's nonsense: if they allow to run arbitrary code written in ANY language, such as PHP, Python, Perl, NodeJS and so on, then banning arbitrary binaries does not improve security in any way, it only creates inconvenience but no real effect. It is simply stupid to impose limitations like this, and it is only done by people who don't understand how computers are attacked and how to keep them secure.
Furthermore, it is terribly inconvenient (although possible) to run Thalassa on a server having no shell access, and shell access is not available with most of 'shared hosting' services.
However, the solution is obvious: you always can run your site on a VPS. Nowadays, a VPS might be even cheaper than shared web-hosting. Visit, e.g., lowendbox.com to pick a server under $2 a month (sometimes there are even offers for $1 per month). Thalassa is so light-weight that you can run literally hundreds of Thalassa-managed sites on a single low-end VPS, so paying these $2 per month, you can invite all your friends to host their sites.
Running sites on a VPS (or, broadly speaking, on a Unix computer you've got root access to, be it virtual or real) is the thing Thalassa is best suited for. With most other CMSes, you might not want to do so, as they rely upon database management systems, primarily MySQL/MariaDB, so you've got to install a DMBS, run it, create a database, regularly think about making backups of it (and yes, it is not so easy to make a backup of a running database), constantly keep an eye on it, as it tends to fail at the most terribly inconvenient moment, etc. Even worse, other CMSes are usually implemented in interpreted languages with their own ecosystems, and despite these Python and Ruby fans do their best to convince you there are no problems with these, the fact is you'll perhaps end up having to put every single program (including every CMS running a single site) into its own container, like Docker, which, well, these low-end VPSes are usually too low-end to run.
In contrast, Thalassa only consists of two executable binaries, one called
thalassa, which you run to generate your site, and the other
called thalcgi.cgi, which is, well, a CGI :-) — that is,
a program the web server runs when it handles requests for interactive
features of your site. When thalcgi.cgi needs to regenerate a
part of your site, e.g. a page with user comments after a new comment is
left there, it also runs thalassa, so you need both of them
for interactivity. The good news is that they literally depend on
nothing, they can even be built statically and uploaded to the
server (in case no C++ compiler is available there; okay, for a VPS it's
never the case, but sometimes you have to use shared hostings despite you
don't want so).
In its full (interactive-capable) configuration, Thalassa is known to run
with the well-known Apache HTTP server, probably any
version of it you can manage to find these days; at least it is known to
work with Apache 1.3.*, which was declared End-Of-Life in 2010. Certainly
it works with later Apache versions, such as 2.4.* and 2.2.*. The
mod_cgi module must be loaded from within your Apache
configuration. Examples and templates provided along with Thalassa also
rely on the mod_rewrite module. The last but not least, for
the sake of security it is strongly recommended to use
suexec, so that the CGI program runs under a UID different
from the HTTP server's UID, even if you only have one site on your server.
To build Thalassa, just unpack the source tarball, enter the directory and
type make (or gmake, if you're on a BSD-like
system), like this:
tar -xzf thalassa_0.1.0.tgz cd thalassa_0.1.0 make
and then wait a minute. Both thalassa and
thalcgi.cgi binaries will be found in the cms/
subdirectory, which also contains the source code.
In case you have an older gcc compiler, such as gcc 4.* or earlier, it is
necessary to remove some command line flags which actually disable certain
(idiotic) “new features” of later gcc versions. In this case, instead of
just make, issue the following command:
make CC=gcc CXX=g++
By default, both binaries are built statically linked and
stripped. If this is not what you want, add STATIC=
to the command line of make, like this:
make STATIC=
or, if you still want them stripped, like this:
make STATIC=-s
The libraries of Thalassa itself (these found under the lib/
subdirectory) are statically linked into the binaries anyway, because these
libs are never built as shared objects.
Your dynamic binaries will therefore only depend on “system” libs such as
libc, libgcc, libstdc++, linux-vdso and the like, so the binaries' size
only shrinks about 3-4 times; this may be not so bad, but it makes the
binaries totally unportable (most of people aroud think it's the norm, but
we disagree).
The thalassa program can generate a whole site or some parts of
it, as requested by its command line arguments. The content of the site
being generated is determined by sources prepared by the
webmaster. The sources must include one or more configuration files in ini format. Also the sources may (but not
necessarily do) include text files that represent sets of similarly
formatted pages (one file per page, or a directory with a main file and
auxilliary files such as images, to generate a page with files) and
comments (one file per comment). Both page set source files and comment
source files together are referred to as “database”, despite that this
has nothing to do with any DBMSes, Sql and the like; usually the database
for Thalassa is simply a directory with subdirectories containing files
(mainly plain text files, but there can be files of any type as auxilliary
files to generated pages). Each page and comment file may have its own
format and character encoding.
The last kind of the sources is directories or individual files to be copied into the docroot of your site “as is”. These files may even be linked or symlinked instead of being copied, which is useful for large files such as videos, software archives etc.
For a site with no interactive features, that's almost all. You just
prepare the source files, run thalassa and your site is ready.
Interactive-capable sites need the thalassa.cgi binary to be
placed into the site's docroot, together with its configuration file
thalassa.ini, which must be placed in the same directory and
made unreadable for anyone but the user under which the CGI will run.
Typically this means you need to configure and run suexec, so
that thalassa.cgi runs with a uid different from the HTTP
server's uid.
The CGI program has its own database, known as session database, which may be placed outside of
the docroot. You don't need to prepare it anyhow, all you need is to
create a directory and make it writable for the user under which the CGI
works. This directory will be used to store session information, user
accounts, premoderation queue and a spool directory for pages that need to
be regenerated. The main thalassa program only uses the spool
directory, and only when it is explicitly instructed to use it. Typically
this is the case when thalassa is being launched by the CGI.
In the present version, the CGI program only operates on comments: you site visitors can leave new comments, and you as the site's owner can edit the comments and perform moderation and other administration tasks. Pages (unlike comments) can not be created nor edited through the CGI program, so you need to edit the corresponding files manually.
Certainly it is more convenient to edit the files on your own computer rather than on the server; but this raises the question of uploading your changes to the server. Practice shows that the most convenient way to do so is using a verion control system such as git; this way you can also transfer new comments (and all the changes made to comment files through the CGI interface) back from the server to your workstation, having a fully-functional copy of your site locally. However, definitely this is not required, you can, e.g., simply copy the modified files to the server using whatever access method you have.