Back to blogging, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

I generally try to keep an open mind to any suggested change no matter how radical it might be, but in this particular case I think it is quite moronic to believe that a transition from point A (copyright) to point C (no copyright) without at least trying to go through B (permission system) is possible, without severe negative effects on the technological progress. Such a transition does not make sense. Consequently, fighting for such a transition does not make sense as well.

And when activism does not make sense in terms of serving a greater good, then the only explanation I can give is that such activism is driven by each individual activist’s own benefit. This might be just the fun involved in being different (IMHO the vast majority of activists), public relations driven activism, promotion of services etc. The kind of activism which does not serve the greater good has so many faces.

Nevertheless, the problem still remains. The industry has missed the train of the digital world. So, what can we do about that? In my opinion, the very first thing that needs to be done is that both the industry and all those activist and especially hacktivist groups stop acting like morons. Conflict is not the right solution as it leads with mathematical precision to the end of the internet as we know it today. On the other hand, a permission system seems like a good possible solution for most of the existing problems. Let’s stop being part of the problem. That’s a good start.

Some thoughts about Copyright related activism, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

This year we want to do something different, something even grander. ReactOS is quite close to transitioning to beta testing and we are constantly improving the development process itself. However for many core developers ReactOS remains a hobby in which they participate in their spare time as all have other real life obligations to meet. All of the developers are extremely skilled and every contribution they make helps significantly improve ReactOS’ quality.

For the first time ever, the ReactOS Foundation seeks to go beyond the usual small fundraising campaigns aimed at paying infrastructure expenses. We wish to raise money to formally hire as many core developers as possible, to work on the project they believe in, the project they’ve been working on, to transform a hobby into a job so they can dedicate all of their time to the ReactOS project.

In light of the significant advances the project enjoyed thanks to work done as part of Google’s Summer of Code 2011, it became even more obvious that the fastest way to accelerate the development of ReactOS is by directly funding developers to contribute to ReactOS. As such, the project is reaching out to our many fans and believers to help make this happen. Together, we can make ReactOS into a true competitor and alternative for computer users worldwide.

I could not agree more! In my opinion, paid development is a key step in the evolution of the development of free software. The benefits are pretty obvious:

1. The current development model mainly involves people working on FLOSS projects in their spare time. As a result, it has become customary to release incomplete and buggy “stable” releases for us to debug. On the contrary, there are several companies which pay developers to work on FLOSS projects or invest their own capital on the development of a FLOSS project. Comparing the quality of the two kinds of projects, it is quite obvious that paid development results in a higher quality product. Money alone cannot produce quality. But, money can greatly help with the creation of the right environment for the right people to produce a high quality product.
2. Usually, a Do-It-Yourself mentality reigns the FLOSS ecosystem. No matter how important the “freedom to customize” is, it is also extremely difficult for people who are not software engineers or who are extremely busy with other things to follow such practices. Donations currently do not work as they should. Contributing money to a FLOSS project should buy nothing more or less than dedication.
3. Funding the development of FLOSS projects will preserve stability and help them survive in the long run. The users will have a greater assurance that a project won’t be suddenly abandoned or dramatically change its goals. This is very important, especially if you base your own work upon such a project.

Today, there is an abundance of free software out there. But in several cases quality is below par. Both users and developers can change things. In my humble opinion, “paid development” and micro-donations (in the form of a subscription) is the necessary next step in the evolution of the model of FLOSS development.

The ReactOS fundraising campaign‘s goal for 2012 is set at 30000 EUR. This means that if 6000 people donated 5 EUR each, the goal would be met. Quite easy I guess for a vast community like the FLOSS ecosystem. I just donated my 5 EUR. Now, it’s your turn. I’m sure this money won’t be wasted. Even if it is, hell, that’s just 5 euros. But… on the other hand, if this plan works out, it will act as a great example for other open source and free software projects about how they should go ahead. It will also be a great example for us users about how important a micro-donation can be and how much it can change things.

Why ReactOS leads the way with their decision to hire full-time developers, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

gzip and deflate compression support by web browsers, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Mobile version of G-Loaded, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

The first thing that went wrong had to do with testing my backup, a step that was not in my original plan. I keep my server data in encrypted containers on Amazon S3 using duplicity. Although I have restored data from the backup numerous times and I was certain it worked OK, I had this strange idea to test the restoration of the data to a virtual machine at home just to make sure. For that purpose I happened to use a VM whose state had been saved several days ago, meaning that its time was way out of sync. That was a detail I had n’t taken into account. So, when I tried to restore the data on that box, I got a glorious exception from duplicity informing me that it could not find any signatures on the S3 bucket. That message was really unhelpful and it resulted in wasting many hours trying to figure out what was wrong with my backup or duplicity, until I finally realized that it was the box’s wrong time that had caused the exception. Once the time was updated, duplicity worked like a charm.

The second thing that went wrong had to do with pvGRUB, which is based on the grub 0.97 code and used to boot Xen DomUs (guests). Due to some limitations of the VPS provider regarding pvgrub, I have to use a very small partition that contains a GRUB configuration file which eventually boots CentOS (root LVM setup). This small partition was initially formatted using ext3. Again, I had a strange hunch to reformat that small partition to ext4! This would have absolutely no benefit, but at that moment I had just thought “why not?”. I was completely unaware that grub 0.97 and eventually pvgrub did not support the ext4 filesystem. To make things even worse, pvgrub deceptively reported that it had recognized the partition as ext2, but could not locate the file I had configured it to load. Disaster. It was a few hours later, after having gone through several bug trackers and mailing lists, that I realized that pvgrub did not actually support reading from ext4. I reformatted the small partition to ext3 and everything went on smoothly.

If I had stuck to the original plan, none of the incidents above would have taken place. No matter how much I trust free software, deciding to experiment with it while I should be doing a specific job is admittedly one of the worst decisions possible. Regardless of how popular a piece of free software might be, it can still have serious bugs and limitations hidden in the last place you’d ever look. Lesson learned: stay on your path and strictly follow the plan.

Lessons learned from a recent OS upgrade, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

/**
 * Revision management. Store 5 (+1 autosave) revisions per post.
 */
define('WP_POST_REVISIONS', 5);

The above setting forces WordPress to store only the 5 most recent revisions of the content. One extra revision is also saved because of the autosave feature.

The acceptable values for WP_POST_REVISIONS and their meanings are:

• -1: store every revision (this is the default)
• 0: do not store any revisions except for the one used for the autosave feature
• N (integer) > 0: store N revisions per post. Revisions are rotated so that only the N most recent recent ones are available.

After getting rid of all those useless revisions that had piled up over the last months, I’m now quite happy with the size of the database. Although the idea of automatic revisions is fine, in my case, on-demand revisions would have been more useful and would make more sense in the way I author these posts.

Limit the number of stored revisions per post in WordPress, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

First of all, I needed to know whether the /etc/sysctl.conf I had on my box differed from the original one. But, before doing that, I had to know which RPM package had installed that file. So, I used the rpm command to query this file:

# rpm -qf /etc/sysctl.conf
initscripts-9.03.27-1.el6.centos.1.i686

So, the initscripts package had installed /etc/sysctl.conf.

Then I verified the initscripts package:

# rpm -V initscripts
S.5....T.  c /etc/sysconfig/init
S.5....T.  c /etc/sysctl.conf

According to the following table:

S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs
P caPabilities differ

the attributes: size, MD5 checksum and the modification time of /etc/sysctl.conf that existed on my system differed from the attributes of the original file.

Since I had no idea the exact changes I had made to that file at some earlier time, I needed to restore the original and re-modify it from scratch. The new yum “reinstall” command could be used to to do this quite easily.

First, I kept a copy of the current file:

# mv /etc/sysctl.conf /etc/sysctl.conf.modified

Then I reinstalled initscripts using YUM’s reinstall command:

# yum reinstall initscripts
Loaded plugins: downloadonly, fastestmirror, priorities
Setting up Reinstall Process
Loading mirror speeds from cached hostfile
 * base: ftp.ntua.gr
 * epel: ftp.ntua.gr
 * extras: ftp.ntua.gr
 * ius: mirror.rackspace.co.uk
 * updates: centosr3.centos.org
6 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package initscripts.i686 0:9.03.27-1.el6.centos.1 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================
 Package                              Arch                          Version                                           Repository                        Size
=============================================================================================================================================================
Reinstalling:
 initscripts                          i686                          9.03.27-1.el6.centos.1                            updates                          934 k

Transaction Summary
=============================================================================================================================================================
Reinstall     1 Package(s)

Total download size: 934 k
Installed size: 5.4 M
Is this ok [y/N]: y
Downloading Packages:
initscripts-9.03.27-1.el6.centos.1.i686.rpm                                                                                           | 934 kB     00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : initscripts-9.03.27-1.el6.centos.1.i686                                                                                                   1/1

Installed:
  initscripts.i686 0:9.03.27-1.el6.centos.1

Complete!

Verify the initscripts package again:

# rpm -V initscripts
S.5....T.  c /etc/sysconfig/init

No verification errors for /etc/sysctl.conf. Note that reinstalling the package did not touch the /etc/sysconfig/init file. It has been mentioned previously that rpm packages do not overwrite existing configuration files.

I had the original file back and I could then start customizing it from scratch.

Restore original configuration files from RPM packages, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

The 1st Rule of Discussion, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride All
    ...
  </Directory>
  ...
</VirtualHost>

In order to prevent the htaccess lookups on the filesystem without losing the htaccess functionality – at least at the DocumentRoot level- I transformed the configuration to the following:

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride None
    Include /home/example.org/public_html/.htaccess
    ...
  </Directory>
  ...
</VirtualHost>

Let’s see what we have accomplished with this:

1. httpd does not waste any time looking for and parsing htaccess files resulting in faster request processing,
2. the virtual host administrator can still override the configuration options of the document root manually or through the web interface of the web application.

Seems like a win-win situation performance and functionality wise.

But, as usual, there is no win-win situation without a downside. In this case, the above trick weakens the server’s security. Let’s see how.

Although the configuration of a directory can be set in both httpd.conf and the directory’s htaccess file, not all directives can be used in both contexts. htaccess files support a subset of the directives that can be used in the Directory context within httpd.conf. By including the htaccess file in httpd’s configuration the vhost admin is no longer restricted to that subset of directives.

This means that by implementing the above configuration the virtual host administrator is granted more privileges regarding the configuration of the virtual host. This also means that a potential attacker, that would exploit a vulnerability of the web application, would be granted the same privileges once he got write access to that htaccess file.

So, although this trick may seem like a good idea at first, it is in fact a rather bad idea and should never be used in production, unless you trust the virtual host administrator and the web application. I do not intend to use such a configuration and I do not recommend it. There are by far better ways to speed up Apache.

Your comments and suggestions are welcome.

Speed up Apache by including htaccess files into httpd.conf, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.