handyfloss

I found out in FayerWayer about the things you can do with the Wiimonte (the remote of the console) and a GNU/Linux computer with Beryl.

[youtube=http://www.youtube.com/watch?v=ALqduQfm09c&rel=1]

Yes, it seems rather useless… but I looks great! Besides, think of the possibilities. And still some people will keep on saying that Mac and Windows lead the desktop innovation!

Finishing my Ph.D. Thesis really hindered my touch with news, so here it goes, with 2 months’ delay: The French National Assembly switched to GNU/Linux. I read about it in Menéame.net, referring to Barrapunto, referring to Slashdot, referring to PC Advisor, who covers the new (usual cycle of news for the Spanish audience, reading mostly Menéame.net).

The French Goverment also said that all Gov. documents should be available in ODF. This nicely relates to the shameful case of the UPV/EHU (my University).

The Spanish Congress, meanwhile, is still hooked to Windows XP.

Oh my God! (pun intended). Where are we heading?

I just read at DistroWatch that there is a GNU/Linux distro for Christians! According to DistroWatch:

Ubuntu Christian Edition is a free, open source operating system geared towards Christians. Along with the standard Ubuntu applications, Ubuntu Christian Edition includes the best available Christian software. The latest release contains GnomeSword, a top of the line Bible study program for Linux based on the Sword Project.

I might understand that people with different religious beliefs has different needs in terms of software, like the GnomeSword program, for studying the Bible. However… a whole distribution!?

This is getting silly, with people making a fork of Ubuntu “for the left-handed”, “for people with cold feet” or “for people who prefer emacs over vi”. All this is what the friggin’ package manager is for: installing the programs you like!

As the readers of this blog may know, I recently became a Doctor in the University of the Basque Country.

As a follow-up to the Thesis Defense act, there is still some paperwork to be done, as e.g. filling a datasheet called “Teseo”. Anyway, what I will comment applies to all the paperwork I did before, during and after the Thesis Defense.

The matter is that this freaking “Teseo” sheet is available online as a RTF or PDF. An original handwritten copy must be sent to the University, so I used a printed down PDF for that. No problem.

The problem came when the University requested that an “electronic” form be sent by e-mail (for which a scanned copy of my manuscript would not do). These bright minds surely wanted me to fill in the RTF, and send it. However, not everyone who wants to get a Ph.D. has adhered (or wants to adhere) to any expensive and abusive license for a proprietary product like MS Windows or MS Office. Certainly I haven’t, so I had to make do with GNU/Linux and OpenOffice to fill the RTF. The result was crappy, due to incompatibilities of the friggin’ RTF proprietary format… but that I sent.

Now the point is: does the public University of the Basque Country (or the public Spanish Ministry of Education) have any reason to discriminate in favor of the private and foreign company Microsoft? Do we, the tax-payers who put the money for their salaries, have to put up with being forced to use specific proprietary formats to communicate with the public institutions? It disgusts me to no end.

Picture the following example: I want to attend the University, and they tell me that I have to wear shoes for that (e.g., use a computer). OK, this might be more or less arbitrary, but I can accept it. Now, imagine that they ask me to wear Gucci shoes (e.g., a proprietary file format, such as RTF). That would be inacceptable, because a public institution can not favor that way a private company, at least not if there is any conceivable substitute (e.g. acceptable shoes of any other brand). And it doesn’t matter if instead of Gucci they require that one uses any cheaper shoe brand. The problem is not if it is expensive, but rather that they are discriminating against other options. And they have no right to do it. They are there to serve us, not the other way around.

Someone could say that they have to use some electronic format, and any would be equally arbitrary. No, not at all. There is something called “open standards”, to which “things” (e.g. electronic document formats) can adhere. One such standard is the ISO, and one document format adhering to a standard (the ISO/IEC 26300) is the Open Document Format (ODF), so they can use that.

The basics are simple: readers and editors for open formats can be made by anyone freely. No-one can force me to pay them royalties so that they allow me to make a program that reads these documents. With proprietary formats (such as DOC, RTF and others), the owner of the license (e.g. Microsoft) can ban anyone from making a program that writes documents in that format, or charge royalties as they please. Put bluntly: since the exchange of documents in my University depends on proprietary formats (RTF and DOC), Microsoft could decide tomorrow to disrupt its operations by denegating further licenses for e.g. MS Office. Of course, this will not happen, because the University will pay as requested. I call this extorsion, because the University can not afford not to pay, so where do the “free competition” and “open market” ideas fit in here? Moreover, I call the University bunch of fools, because they put themselves in a position that can be extorted. The aforementioned is not possible if one uses open formats, because free (not free of cost, but free as in freedom) document editors are, and will always be, available.

In UNIX-like environments, such as GNU/Linux, command line is often used to operate on a bunch of files, such as:

rm -f *.dat

In the command above, “*.dat” is expanded by the shell (the command interpreter), to all matching files in the present directory (e.g.: “file1.dat file2.dat dont_delete_me.dat this_file_is_rubbish.dat“). However, this expansion is performed as a first step, and then the expanded command line is executed, e.g.:

rm -f file1.dat file2.dat dont_delete_me.dat this_file_is_rubbish.dat

This behaviour can potentially fail if a lot of files match the *.dat, because there is an upper limit to how wide a command line can be (brutally high, but finite). This can happen, for example, if you try to delete the contents of a directory with 100,000 files, and use rm -f * (yes, this can happen). For example, a ls in a directory with 100,000 files works fine, but an rm * does not:

Bart[~/kk]: rm *
/bin/rm: Argument list too long.

To avoid this problem, we can make use of xargs and echo (since echo does not seem to suffer from this argument number limitation), in the following way:

echo * | xargs rm -f

Now, xargs takes care of the argument list, and processes it so that rm does not see an endless argument list.

xargs can also be given other uses. For example, consider the following example: We want to convert some OGG files to MP2 (I won’t be caught dead near an MP3, due to its patent issues), so that a Windows luser can hear them. We can use oggdec to convert OGG to WAV, then toolame to convert WAV to MP2. Now, oggdec accepts multiple arguments as input files to convert, so the following works:

oggdec *.ogg

The above generates a .wav for each .ogg in the argument list. However, toolame does not work like that; it expects a single argument, or, if it finds two, the second one is interpreted as the desired output file, so the following fails (too many arguments):

toolame *.wav

This is where xargs can come in handy, with its -n option (see the xargs man page). This option tells xargs how many arguments to process at the same time. If we want each single argument to be processed separately, the following will do the trick:

echo *.wav | xargs -n 1 toolame

In the above example, toolame is called once per WAV file, and sees a single WAV file as argument each time, so it generates a .mp2 file per .wav file, as we wanted.

Rembember I mentioned PowerDot for LaTeX? PowerDot is a LaTeX class to produce PowerPoint-like presentations. It creates PDFs that can be read fullscreen with any PDF reader, and turn out to be very nice looking presentations.

I am now fiddling with it, and wanted to do a custom style. I have read the PowerDot Manual[PDF], and it says all you have to do is to copy and rename an existing style, then modify it:

% cd /usr/share/texmf-texlive/tex/latex/powerdot/
% cp powerdot-default.sty powerdot-isilanes.sty
% vi powerdot-isilanes.sty

Then, put style=isilanes in your .tex, et voilà!. Well, it fails misserably, saying (among the usual garbage):

! Class powerdot Error: unknown style `isilanes'.

But the .sty is there!

OK, the problem is that LaTeX “doesn’t know” you added the style. To remind it, in my Debian Etch box:

% dpkg-reconfigure tetex-base

or, much better (thanks to a comment by bjacquem):

% texhash

This seems to “refresh” the internal LaTeX database, and now it works.

[This entry is also available in English|English PDF|PDF en castellano]

Los excépticos del movimiento FLOSS suelen decir que el Software Libre tiene, en general, menos bugs explotados que el software privativo, solamente porque es menos popular que este. Argumentan que, como el FLOSS tiene menos usuarios, los crackers estarán menos interesados en malgastar su tiempo intentando explotar los bugs que pudiera tener. La mayor base de usuarios del software privativo daría además, según ellos, una mayor publicidad a sus bugs, y sus modos de explotación se difundirían más rápido. El corolario a esta teoría sería que la popularización de aplicaciones FLOSS (p.e. Firefox), llevería a un incremento en el número de bugs descubiertos y explotados, llegando eventualmente a un estado similar al del software privativo actual (p.e. “Cuando Firefox sea tan popular como Internet Explorer, tendrá tantos bugs como Internet Explorer.”).

El objetivo de este artículo es demostrar matemáticamente la total insensatez de tal teoría. Específicamente, argumentaré que un aumento en el tamaño de la comunidad de un proyecto FLOSS lo mejora de al menos 3 formas:

1. Desarrollo acelerado
2. Menor vida media de bugs abiertos
3. Menor vida media de bugs explotados

Una explicación más extensa está disponible en formato PDF. Lamento que las fórmulas matemáticas en HTML sean de calidad francamente pobre, pero no tengo ni tiempo ni habilidad para mejorarlas. Si el lector está interesado en fórmulas bonitas, recomiendo acudir al PDF.

Este blog, y el PDF que enlazo, están liberados bajo la siguiente licencia:

Esta obra está bajo una licencia de Creative Commons.

Lo que esto significa, básicamente, es que eres libre para copiar y/o modificar este trabajo como gustes, y redistribuirlo cuanto quieras, con dos únicas limitaciones: que no le des uso comercial, y que cites a su autor (o al menos enlaces a este blog).

1 – Proposiciones y derivación

Tenemos un proyecto FLOSS P, nuevas versiones del cual se liberan cada T tiempo. Cada versión se asume que incorpora G nuevos bugs, y las sucesivas versiones serán liberadas cuando todos los bugs de la anterior sean parcheados. En un momento determinado habrá B bugs abiertos (de los G originales).

Asumo que la velocidad de parcheo es proporcional al tamaño de la comunidad de usuarios (U):

dB/dt=-K_pU

1.1 – Desarrollo acelerado

De arriba, la dependencia temporal del número de bugs abiertos:

B = G – K_p U t

El tiempo entre versiones (T), de B = 0:

T = G/K_pU

De manera que el tiempo entre versiones se acorta para U creciente.

1.2 – Menor vida media de bugs abiertos

En un período de tiempo dt, se parchean (-dB/dt)dt bugs, siendo su edad t. Si llamamos τ a la vida media de los bugs, tenemos la definición:

τ = (∫t(-dB/dt)dt)/(∫dB)

De ahí se deduce:

Ï„ = T/2

Esto es: la vida media de los bugs es siempre la mitad del tiempo entre versiones, el cual (como se ha mencionado) tiene una proporcionalidad inversa con U.

1.3 – Fracción de bugs explotados antes de ser parcheados

Definimos la siguiente velocidad de explotación de bugs, donde B_x es el total de bugs explotados, K_x es la “eficiencia de explotación” de los crackers (cuya cantidad se asume proporcional a U), y B_ou es la cantidad de bugs abiertos y sin explotar:

dB_x/dt = K_x U B_ou

También definimos α = B_ox/B, donde B_ox es la cantidad de bugs abiertos y explotados.

Se puede derivar la evolución temporal de α:

α(t) = 1 – exp(-K_x U t)

Tras ello definimos γ = K_p/K_xG, y derivamos la fracción de los bugs G que terminan siendo explotados para un tiempo t:

B_x(t)/G = 1 – γ + (γ – 1 + t/T)exp(-K_x U t)

Resolviendo para t=T, y tomando en cuenta que T=G/K_pU, obtenemos la fracción de los bugs totales que son explotados en algún momento durante el período entre versiones (F_x):

F_x = 1 – γ + γ exp(-1/γ)

Nótese que F_x es independiente de U, esto es, aunque aumente el tamaño de la comunidad de usuarios, no aumenta la fracción del total de bugs que acaban siendo explotados (aunque un crecimiento de la comunidad traiga asociado un aumento colateral del número de crackers).

1.4 – Menor vida media de bugs explotados

Deseamos saber cuánto tiempo permanecen sin parchear los bug explotados, y llamamos a este tiempo τ_x. Tras un desarrollo ligeramente complejo, pero derivando siempre de equaciones previamente definidas (ver la versión PDF), obtenemos una expresión realmente simple para τ_x:

τ_x = F_xτ

Esto es, el tiempo medio de explotación de los bugs explotados es proporcional a τ, el cual a su vez es proporcional a T, o inversamente proporcional a U.

2 – Conclusiones

El eslogan “Más popularidad = más bugs” es un non sequitur. De acuerdo con el simple modelo que bosquejo aquí, cuanto más amplia sea la comunidad de usuarios de un programa FLOSS, más rápido serán parcheados los bugs, incluso admitiendo que a más usuarios, más crackers entre ellos, dispuestos a acabar con él. Incluso para crackers que sean más efectivos en su desempeño que los usarios de buena fe en su trabajo de parcheo (K_x >>> K_p), aumentar el tamaño de la comunidad reduce el tiempo que los bugs permanecen abiertos y también cuánto tiempo tardan en parchearse los bugs ya explotados. No importa cuán torpes sean los usuarios, y cuán rapaces los crackers, el modelo libre (por medio del cual se da acceso al código a los usuarios, dándoles así poder para contribuir al programa) asegura que la popularización es positiva, tanto para el programa como para la propia comunidad.

Comparemos esto con un modelo cerrado, en el que una base de usuarios mayor puede incrementar el número de crackers atacando a un programa, pero ciertamente añade poco o nada a la velocidad con que el código es parcheado y corregido. Es de hecho el software privativo el que debe temer su popularización. Es fácil de ver que cuando una pieza determinada de software privativo alcanza una cierta “masa crítica” de usuarios, los crackers pueden potencialmente desmoronar su evolución (digamos, haciendo Ï„_x = T, F_x = 1), porque (a diferencia del FLOSS), G, P, y por lo tanto T, son constantes (ya que dependen únicamente de los vendedores del software).

[Esta entrada está también disponible en castellano|English PDF|PDF en castellano]

It is often said (by FLOSS-skeptics), that Free Software has less exploited bugs than the Proprietary Software because it is less popular. They argue that, since less people uses FLOSS, the crackers are less inclined to waste their time exploiting the bugs it could have. The greater user base of the proprietary software would also, in their words, make bugs more prominent, and their exploits spread faster. The corollary of this theory would be that popularization of FLOSS applications (e.g. Firefox), would lead to an increase in the number of bugs discovered and exploited, eventually reaching a proprietary-like state (e.g. “Firefox will have as many bugs as IE, when Firefox is as popular as IE”).

In this blog entry I will try to outline a mathematical model, proposed to demonstrate the utter nonsense of this theory. Specifically, I will argue that an increase in community size benefits a FLOSS project in at least 3 ways:

1. Faster development
2. Shorter average life of open bugs
3. Shorter average life of exploited bugs

A more thorough explanation is available in PDF format. Recall that the math display in HTML is generally poor (much more so when I don’t have the time nor skills to tune it). If you like pretty formulas, the PDF is for you.

Both this blog entry and the linked PDF are released under the following license:

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.

What this basically means is that you are free to copy and/or modify this work, and redistribute it freely. The only limitations are that you can not make it for profit, and that you have to cite its original author (or at least link to this blog).

1 – Propositions and derivations

We have a FLOSS project P, new versions being released every T time, and each version incorporating G new bugs. Each new version will be released when all bugs from the previous release have been patched. At any point in time, there will be B open bugs (remaining from G).

The patching speed is assumed proportional to the size of the comunity of users (U):

dB/dt=-K_pU

1.1 – Faster development

From above, the time dependency of open bugs:

B = G – K_p U t

The inter-release period (T), from B = 0:

T = G/K_pU

So the inter-release time (T) is shortened for growing U.

1.2 – Shorter average life of open bugs

In a dt time period, (-dB/dt)dt bugs are patched, their age being t. If we call Ï„ the average lifetime of bugs, we have the definition:

τ = (∫t(-dB/dt)dt)/(∫dB)

From that it follows:

Ï„ = T/2

So, the average life of open bugs equals half the inter-release time, which (as stated above) has an inverse proportionality with U.

1.3 – Fraction of bugs exploited before being patched

We define the following bug exploitation speed, where B_x is the total amount of exploited bugs, K_x is the “exploiting efficiency” of the crackers (whose amount will be proportional to U), and B_ou is the amount of open and unexploited bugs:

dB_x/dt = K_x U B_ou

We also define α = B_ox/B, where B_ox is the amount of open and exploited bugs.

It can be derived the evolution of α with time:

α(t) = 1 – exp(-K_x U t)

We then define γ = K_p/K_xG, and derive the fraction of G bugs that end up exploited by time t:

B_x(t)/G = 1 – γ + (γ – 1 + t/T)exp(-K_x U t)

Solving for t=T, and taking into account that T=G/K_pU, we get the fraction of total bugs that gets exploited ever, during the inter-release period (F_x):

F_x = 1 – γ + γ exp(-1/γ)

Recall that F_x is independent of U, that is, increasing the size of the user community does not increase the fraction of total bugs that get exploited ever, even though the amount of crackers is increased along with the user base.

1.4 – Shorter average life of exploited bugs

We want to find out how long exploited bugs stay unpatched, calling this time Ï„_x. After some slightly complex algebra, but always deriving from the previously defined equations (see PDF version), we obtain a fairly simple expresion for Ï„_x:

τ_x = F_xτ

That is, the average exploitation time of exploited bugs is proportional to Ï„, which is to say it is proportional to T, or inversely proportional to U.

2 – Conclusions

The “Increasing popularity = Increasing bugginess” motto is a non sequitur. According to the simple model outlined here, the broader the user community of a FLOSS program, the faster bugs will be patched, even admitting that an increase in user base brings an equal increase in the number of crackers committed to doom it. Even for crackers that are more effective in their cracking work than the bona fide users in their patching work (K_x >>> K_p), increasing the community size does reduce how long the bugs stay unpatched and also how long the exploited bugs stay unpatched. No matter how clumsy the users, and how rapacious the crackers, the free model (whereby the users are granted access to the code, and thus empowered to contribute to the program), ensures that popularization is positive, for both the program and the community itself.

Compare that with a closed model, in which an increased user base may boost the number or crackers attacking a program, but certainly adds little, if anything, to the code patching and correcting speed. It is actually proprietary software that should fear popularization. It is easy to see that when a particular proprietary software piece grows over a certain “critical mass” of users, the crackers could potentially disrupt its evolution (say, Ï„_x = T, F_x = 1), because G, P and thus T, are kept constant (depend only on the sellers of the code).

I have just read a rather interesting article in Science about the economics of information security (R. Anderson and T. Moore, Science, 2006, 314, 610), and I would like to comment some quotes of it:

There has been a vigorous debate between software vendors and security researchers over whether actively seeking and disclosing vulnerabilities is socially desirable. Rescorla has argued that for software with many latent vulnerabilities (e.g. Windows), removing one bug makes little difference to the likelihood of an attacker finding another one later[1].

Quite interesting! First, even a paper on Science not only regards Windows as a piece of software with a virtually endless reservoir of internal errors, but it even uses it as a paradigmatic example of such a case. Second, it deems such software as not worth patching, and bugs not worth being disclosed (security through obscurity), because they are so many.

[…] [Rescorla] argued against disclosure and frequent patching unless the same vulnerabilities are likely to be rediscovered later. Ozment found that for FreeBSD[2] […] vulnerabilities are indeed likely to be rediscovered[3]. Ozment and Schecher also found that the rate at which unique vulnerabilities were disclosed for the core and unchanged FreeBSD operating system has decreased over a 6-year period[4]. These findings suggest that vulnerability disclosure can improve system security over the long term.

I have read [1] and [3] very briefly, and Ozment seems very critical of Rescorla’s results. However, the comparison between Windows and FreeBSD (I think they mean OpenBSD), which is FLOSS, is quite nice. Windows is so buggy that patching it is hopeless. FreeBSD has seen a decline in the number of disclosed bugs (remember that, being FLOSS, all the bugs found by developers, mantainers and users are disclosed), related to the fact that each bug fixed actually means a reduced probability of finding new bugs (because the total is not endless).

The bottom line is that, for a good piece of software (one that is not so bug-ridden that crackers never “rediscover” an old bug, because there are sooo many new ones to discover), disclosing the bugs is better. It is so because it speeds the patching rate, which in turn reduces the amount of exploitable bugs, which in turn improves the security. The connection between patching bugs and reducing significantly the amount of exploitable bugs can be made when the amount of bugs is small enough that new crackers are likely to rediscover old bugs, and then it would have paid to patch those bugs. Notice also that this is an auto-catalytic (self-accelerated) process: the more bugs disclosed, and more bugs patched, the less bugs remain, so the more it pays to further disclose and patch the remaining bugs, because the less bugs, the relatively more it pays to patch.

Vulnerability disclosure also helps to give vendors an incentive to fix bugs in subsequent product releases[5]. Arora et al. have shown through quantitative analysis that public disclosure made vendors respond with fixes more quickly; the number of attacks increased, but the number of reported vulnerabilities declined over time[6]

Good point! Not only disclosing the bugs is good for the consumers because it directly increases its quality, but also because it helps enforce a better behavior of the vendors. This is a key idea in the article, which delves in the fact that security policies are best when the one enforcing them is the one suffering from their errors. However, nowadays there is little pressure on the vendors to produce more secure software, because the buyer has little knowledge to judge this aspect of the quality, and ends up favoring a product for its looks or the alleged features, regardless of stability or security. Disclosing the bugs helps the buyer to assess the security of a program, thus making a better-balanced choice when buying. This, in return, leads to a more secure software in general, because vendors will have a big incentive to make their products more secure (which they don’t really have now).

[1] E. Rescorla, paper presented in the Third Workshop on the Economics of Information Security, Minneapolis, 13 to 14 May 2004 (PDF)
[2] I suspect the authors are mistaking OpenBSD for FreeBSD
[3] A. Ozment, paper presented at the Fourth Workshop on the Economics of Information Security, Cambridge, MA, 2 to 3 June 2005 (PDF)
[4] A. Ozment, S.E. Schechter, paper presented at the 15th USENIX Security Symposium, Vancouver, 31 July to 4 August 2006 (HTML).
[5] A. Arora, R. Telang, H. Xu, paper presented at the Third Workshop on the Economics of Information Security, Minneapolis, 13 to 14 May 2004 (PDF)
[6] A. Arora, R. Krishnan, A. Nandkumar, R. Telang, Y. Yang, paper presented at the Third Workshop on the Economics of Information Security, Minneapolis, 13 to 14 May 2004 (PDF)

I am working out a Wiki page for a small sized group of users of a supercomputer at the UPV/EHU.

You might find this comparison useful.

My impressions so far:

[[MoinMoin]]

See more comprehensive HowTo at this more recent post

To install it, create a directory for it (e.g., in your /home), then copy some files to it (after installing the python-moinmoin and moinmoin-common packages, in Debian):

mkdir my_moinmoin_dir
cp /usr/share/moin/config/wikiconfig.py my_moinmoin_dir
cp /usr/share/moin/server/moin.py my_moinmoin_dir
cp /etc/moin/mywiki.py my_moinmoin_dir

Then, edit the files (mainly wikiconfig.py, and run my_moinmoin_dir/moin.py to start up the server.

If you want to make a single Wiki (not a “farm”), then remove (or better, just rename) the file /etc/moin/farmconfig.py (so that it is not read).

This one was easy to install, but has a “small” drawback: the CamelCase internal links. How freaking silly is that? First off, it makes writing CamelCase words that are not links impossible. Second, how can one make a link that displays a text X, but points to page Y?. If only CamelCase generates links, ThisText will link to the page called ThisText. This means that there is no way to put a custom string as link, pointing to a custom page. This is frustrating at the very least. Third, how does one make a one-word link?

These three concerns are taken care of, fortunately. A custom string (not CamelCase) can be used as link like that:

["Custom string here"] (links to page called Custom string here”)

The text of the link can differ from the title of the refered page like this:

[:The Refered:The Text] (displays “The Text”, while pointing to page “The Refered”)

I found out about this workaround after I started to write this page, so sue me for complaining.

It is also problematic (for a dumbass like me) to make the Wiki accesible to machines other than localhost. That is, over the Intra- or Internet. I’m working on in.

DidiWiki

Pros: it is very simple. It is a breeze to install and run. Under Debian, just aptitude install didiwiki, then run didiwiki -p 8080, open a web browser, and put http://localhost:8080 at the location bar. The default port is 8000 (if you run just didiwiki), but for me it fails. The -p can be used to attach DidiWiki to any port.

Contras: it is very simple. Editing is very easy, but… there is no preview! Is there a way to hack a preview into it? I do not know, and the project having made no progress since 2004 smells like there will never be such an upgrade.

More important: there is no “history” of the edits into a page. You can see a list of “recently edited pages”, but no such a list for each single page, or a diff between to arbitrary versions, or reversion capabilities.

On the brigth side, it is immediate to access the Wiki from any other computer… I just don’t know if this is a feature or a security hole :^)

DokuWiki

To install under Debian, do aptitude install dokuwiki, answer the questions it makes, then run dpkg-reconfigure dokuwiki to see if it asks for some more options (e.g. if Wiki will be accesible from localhost, a subnet, or the whole Internet, or what directory to put it under). Then, restart the web server (if you are running Apache2: /etc/inid.d/apache2 restart), and you are done! Now, simply point your broser to http://localhost/dokuwiki/, and you can start using it (replace dokuwiki/ with whatever dir you chose when configuring, if you changed the default).

At first sight is looks good. However, it keeps giving me errors when saving a page. The page gets full of the following:

Warning: preg_match() [function.preg-match]: Compilation failed: repeated subpattern is too long at offset 17093 in /usr/share/dokuwiki/inc/common.php on line 391

It actually saves the page… but the error is annoying at least, dangerous at worst. I suppose I could try to read the source code and fix it (it is PHP, and I have spotted the line with the error… hehehe, line 391, that is), but I do not have the programing skills, I fear.

I’ll give it a try…

Okay, I might have corrected the first bug of a FLOSS program in my life: the 391th line giving an error reads:

if( preg_match('#('.join('|',$re).')#si',$TEXT, $match=array()) ) {

I read the PHP manual for preg_match, and found out that this function chokes for long strings. They say that you can use substr instead, if you are only using the function to find out if some substring exists inside some string (substr is faster and more efficient than preg_match). So I commented out the line above, and wrote instead:

/*if( preg_match('#('.join('|',$re).')#si',$TEXT, $match=array()) ) {*/
if( strpos('#('.join('|',$re).')#si',$TEXT, $match=array()) ) {

Now it works (or pretend it does) like a charm!! UPDATE: the above is rubbish :^( Find a better solution at the DokuWiki bugtracker.

Appart from that, DokuWiki seems to have a decent page edit history, and you can compare different versions with the current one. Pity it doesn’t seem to be possible to compare different old edits between them, as it is with MediaWiki (the engine behind Wikipedia). DokuWiki also looks a bit ugly, but I guess one can correct that with CSS, skins or whatever.

It also looks more difficult to configure than MoinMoin, for example I do not see an easy way to create users. Probably I should just RTFM, as there must be an easy explanation for all that… but I’m too lazy, and MoinMoin is more intuitive on this account (and looks prettier).

ErfurtWiki

It goes under the name ewiki, as a Debian package. However, when I tried to install it, it requested PHP4 (I have PHP5 installed), so I refused to downgrade my PHP and ewiki would not install.

Kwiki

It needs to run as a Perl cgi module. After installing, add the following to your /etc/apache2/apache2.conf:

ScriptAlias /kwiki/ /var/www/kwiki/

Options +ExecCGI

The ScriptAlias makes the browser go to /var/www/kwiki/ when pointed to /kwiki. The Directory block lets Apache execute scripts in that dir.

One then needs to install modules, from CPAN.

All in all, not too easy, a bit annoying, and a bit buggy. Didn’t work well for me.

MediaWiki

Time to give the engine behind Wikipedia itself a try. Probably it is a big overkill for my needs, but what the heck…

First: it is a breeze to install under Debian. First, aptitude install mediawiki, which will automatically install mediawiki1.7, php5-cli and php5-mysql, plus PHP5 and MySQL, if you don’t have them installed. It is also suggested to install memcached.

After aptitude installation, steer your browser to http://localhost/mediawiki/config/index.php (as the README.Debian.gz file says), and fill the required data. After everything is correctly set, copy the Settings file to its final location (also said in the README):

cp /var/lib/mediawiki1.7/config/LocalSettings.php /etc/mediawiki1.7/

URL beautification HowTo

Following instructions at the WikiMedia site.

The default MediaWiki URL is:

http://mywiki.site.tld/wiki/wiki/index.php?title=Article_name

This could be rewriten as:

http://mywiki.site.tld/wiki/Article_name

To achieve that, add the following to /etc/apache2/httpd.conf:

AcceptPathInfo On

#These must come last, and in this order!
Alias /wiki /usr/share/mediawiki1.7/index.php
Alias /index.php /usr/share/mediawiki1.7/index.php

Then the following to /var/lib/mediawiki1.7/LocalSettings.php:

$wgScriptPath = "/mediawiki";
$wgArticlePath = "/wiki/$1";

Then enable the rewrite PHP module, and reload Apache:

ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load
/etc/init.d/apache2 reload

Now just point your broser to http://localhost/wiki/, and you are done.