G-Loaded Journal » Open Source

Why ReactOS leads the way with their decision to hire full-time developers

George Notaras — Wed, 02 May 2012 23:07:50 +0000

Software has become part of our lives. Businesses, homes and even individuals more and more rely on software to meet their goals and serve their needs. Recently, I ~~had~~ tried to have a discussion with people who are active in the FLOSS ecosystem about if and how the development process of free software could be improved in order to increase its quality and efficiency. As usual, the conservative minds within the community did not let the discussion get far. This was not the first time nor the first place I tried to start a discussion like that. Nevertheless, the outcome has always been the same.

A few minutes ago I ran across a news item about the ReactOS community seeking to raise funds in order to hire developers who will work full-time on the project. The community realizes the fact that dedication to the project is the determinant factor in the process of creating a high quality product. In their announcement we read:

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:

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.
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.
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.

Lessons learned from a recent OS upgrade

George Notaras — Sat, 28 Apr 2012 07:28:33 +0000

From the time I had set up my first server at home over a decade ago, I’ve performed numerous operating system upgrades. Usually, it used to take me several hours – if not days – to complete each upgrade and make sure that everything would work as expected. During all these years, I’ve been working hard whenever time permitted it in order to make several pieces of software work flawlessly together requiring the least possible time for manual maintenance. Despite the deployment of my services having reached a high level of automation, I recently spent almost a whole day upgrading CentOS in one of my remote boxes.

According to my initial plan this procedure shouldn’t have taken longer than 2-3 hours. I had simulated it in Virtualbox at home and I knew exactly what to expect. Unfortunately, I didn’t strictly follow the plan, but deviated from it 2 times and this almost cost me the whole day.

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.

Restore original configuration files from RPM packages

George Notaras — Mon, 26 Mar 2012 20:24:27 +0000

By default, when the user installs software through the RPM Package Manager or through YUM, usually, the software’s configuration files included in the RPM do not replace the existing configuration files on the filesystem, but, if they differ from those that currently exist, they are saved with the rpmnew extension. In case the rpm is already installed and is the latest version, the quickest way to get the original configuration file back is to uninstall and install the package again. Today, while on CentOS 6.2, I needed to restore the original /etc/sysctl.conf file, which is part of the initscripts package. In this case, uninstalling initscripts was out of the question as it would also remove half of the installed packages due to dependencies. So, I grabbed the chance to figure out and document what would be the quickest and easiest way to restore /etc/sysctl.conf, excluding downloading the package itself and extract the RPM contents. Fortunately, as soon as I opened yum’s man page and having spotted the new reinstall command, the solution was quite obvious.

For completeness, I hereby document the whole procedure that involves the verification and restoration of the original /etc/sysctl.conf hoping that new users might find these notes helpful.

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

George Notaras — Thu, 09 Feb 2012 06:28:02 +0000

I cannot overstate how disappointed I am after having a discussion with people who tend to partially mix the various declarations of Rights and the Law in order to make a point valid enough to justify their actions. I am not really the one to tell whether such behavior derives from competence or incompetence. What i do know is that I will never again join any discussion which, at least, is not based on common sense. Ever.

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

Speed up Apache by including htaccess files into httpd.conf

George Notaras — Mon, 28 Nov 2011 05:12:59 +0000

It is widely known that, if virtual hosts in Apache (httpd) are configured to permit vhost administrators override specific configuration options at the directory level using htaccess files, the web server consumes valuable time in order to check whether an htaccess file exists in every directory included in the requested path and parse it. On the other hand, many popular web applications utilize htaccess files, especially those residing in the DocumentRoot, in order to implement pretty URLs or HTTP redirections, which is extremely convenient since the virtual host owner does not have to edit httpd’s configuration directly. So, I had the idea to include the htaccess file of the DocumentRoot directory on the filesystem into the virtual host’s configuration.

Suppose we have the /home/example.org/public_html/ directory on the filesystem, which serves as the document root of our virtualhost. The relevant httpd configuration for that vhost would look like this:


  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  
    AllowOverride All
    ...
  
  ...

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:


  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  
    AllowOverride None
    Include /home/example.org/public_html/.htaccess
    ...
  
  ...

Let’s see what we have accomplished with this:

httpd does not waste any time looking for and parsing htaccess files resulting in faster request processing,
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.

The new amateuristic release strategy of Firefox

George Notaras — Wed, 28 Sep 2011 07:05:26 +0000

I have been using Firefox since it was called Phoenix (version 0.5). I’ve witnessed all the effort that has been put into making this web browser a success. It is still the only web browser I can fully trust. Suddenly, earlier this year, the Mozilla Foundation decided to change the release strategy of the project for obvious marketing reasons and release several major versions within a short period of time. It was inevitable that such a change of release cycles would introduce numerous incompatibility issues with the available extensions. Such problems should have been solved before switching release strategies.

Today I happened to browse the tech section of Digg and stumbled upon this news item about the release of Firefox 7. Some of the comments pretty much summarize my feelings about the new release strategy:

- Wtf I just installed 6….
- I just installed 5.
- Once the version number is up to 50 in a short amount of time, it will become a joke, and future releases will be ignored.
- Firefox is killing themselves is what they’re doing. People use Firefox for the plugins, every new version installation kills all plugins. After I install this, there’s technically no reason for me to use Firefox over Chrome anymore. Why doesn’t Mozilla understand this???
- Pro tip: People aren’t switching from Firefox to Chrome because it’s got a “better” version number, guys.

I would add that it is not necessary to go through all the numbers from 5 to 14 to catch up with Chrome in terms of major version numbers. These could be just skipped and go straight to 14!

PS: The Firefox extension of a software I had paid for had stopped working since the FF3 -> FF4 upgrade. A workaround was released by the company for FF4, but as soon as FF5 came out it stopped working again. I’ll be straight. I’d rather use Internet Explorer or Chrome or Opera instead of asking the company for a workaround every time the Mozilla folks roll out a new major release of Firefox.

The new amateuristic release strategy of Firefox, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

WordPress is getting better

George Notaras — Tue, 27 Sep 2011 23:48:18 +0000

The first time I used WordPress back in September 2005 I considered it to be the content publishing platform of choice as far as a personal or business website was concerned. It was easy to set up and publish content and, also, easy to customize, even with ugly hacks. Today I still consider WordPress to be the overall best choice, despite the fact it still does not excel in any particular sector. Although I am not a pro, I have enough experience to say it’s the engine with the most acceptable trade-off between ease of use, security, features, ease of customization and being a solid base for development upon it. It is also one of those open-source projects that can create business opportunities for software engineers, system administrators, web designers, internet advertisers and marketers. The huge and active community of users and developers have boosted this project over the years. It proves that, if an open-source project is surrounded by a big active community and has good marketing (like WordPress had all these years) it can fly and create business opportunities in many sectors. During the last days I spent much time trying some of the features that have been implemented in the newer releases of WordPress and also various plugins. I must admit that today, by using WordPress, it is just a matter of some hours to have a high performance, good looking and feature rich small web site from scratch with minimal cost.

WordPress is getting better, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability

George Notaras — Tue, 27 Sep 2011 20:40:45 +0000

It’s been a while since the details of an SSL/TLS vulnerability have been released to the public. Since then, security experts have worked on the issue and have released a whitepaper describing how to mitigate the attack, known as BEAST (Browser Exploit Against SSL/TLS).

From the security researchers’ article:

The problem lies in the way that block ciphers are used in SSL/TLS. Block ciphers are generally operated in one of several modes that define how encrypted blocks are manipulated to ensure complete confidentiality. Cipher Block Chaining, or CBC mode, is used in SSL for all block ciphers, including AES and Triple-DES. The BEAST attack relies on a weakness in the way CBC mode is used in SSL and TLS. Non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, are not vulnerable.

There have been several suggested mitigations that can be put into play from the perspective of the client, such as reorganizing the way the data is sent in the encrypted stream. Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers.

Researchers have concluded that the RC4 (Alleged RC4) based cipher suites are not vulnerable to the BEAST attack, while CBC (Cipher Block Chaining mode) based cipher suites are. This involves both the TLS 1.0 and the SSL 3.0 protocols. On the contrary, TLS 1.1 and 1.2 have not been found to be vulnerable, but their use is very limited since they haven’t been adopted by the majority of HTTP clients and servers yet.

So, the use of RC4 based ciphers is all that is left for the moment. The security experts have released a list of cipher suites that is suitable for use in the configuration of the mod_ssl module for httpd:

SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL

They have also released a one-liner list of ciphers suitable for use in the relevant fields of the Local Group Policy Editor in Windows Server boxes.

However, there is no info about configuring the mod_gnutls module for apache to use RC4 based ciphers, so, as a dedicated user of mod_gnutls, I decided to release this tip. All you have to do is set the preferred ciphers in the GnuTLSPriorities directive. In this example we use the TLS 1.0 protocol:

GnuTLSPriorities NONE:+VERS-TLS1.0:+ARCFOUR-128:+RSA:+SHA1:+COMP-NULL

Visiting a secure web site that has been configured using any of the methods described above and by checking the information of the secure connection to that website, you should see the following message:

Firefox message about using RC4 encryption cipher

This means that everything is working correctly.

As always, comments and suggestions are welcome and appreciated.

How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Mozilla Thunderbird speed up

George Notaras — Fri, 09 Sep 2011 12:25:13 +0000

Mozilla Thunderbird is of those pieces of software I could say I am a fan of, but since I upgraded from TB3 to TB5 and recently to TB6, I’ve been experiencing various problems with the application’s overall speed and responsiveness. Using Thunderbird almost felt as if it was reading its data from the internet. Working with it had become an unpleasant experience, until I found some tips about how to make it more responsive. It seems that versions 5 and 6 try to use hardware acceleration to render the application’s user interface and, apparently, this does not work very well with my hardware. Anyway, here is what you have to do in order to restore Thunderbird 6 responsiveness to that of version 3.

Open TB’s Config Editor (tools/options/advanced/general-tab/config-editor-button). Search for the following settings and double-click on them to set them to TRUE.

gfx.direct2d.disabled
layers.acceleration.disabled

Also, open the Add-on Manager (tools/add-ons/plugins) and disable all plugins that do not need to be enabled in your email client. Note that the plugins are a different thing than the extensions. I disabled them all in my TB.

Finally, restart Thunderbird.

This has worked for me. Thunderbird 6 now feels as responsive as TB3 was.

Mozilla Thunderbird speed up, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Why free should not always mean cost-free

George Notaras — Sat, 14 May 2011 06:11:15 +0000

More and more I realize that there is a misconception about free software. Many people tend to believe that free software actually means software that should not cost any money. They somehow find natural and fair the fact that some people may work voluntarily in order to produce software, which the rest can use to make money without having any legal obligation to contribute either money or effort back upstream.

As I see it, free software should be free from cost for all to use and build upon, BUT using or building upon free software to make a profit should not be cost-free. That’s a straightforward and very fair model. Also, it seems to be the only realistic concept that could drive money back to those who invested their time and effort producing free software. I know that currently there is no free software license that makes a distinction between commercial and non-commercial use and thus be the solid ground for such a software production ecosystem. But, who knows… maybe we see one in the near future. Such a software license would make a difference in the way we perceive the “doing business with free software” concept that people talk about these days.

For content and media, there are the Creative Commons licenses, some of which make it possible for creators to provide their work for free, while at the same time they still reserve the right to selectively make their work available for commercial purposes under different terms. That’s the beauty of those licenses. They are made to solve real problems and that’s why I highly respect them.

Why free should not always mean cost-free, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

G-Loaded Journal » Open Source

Why ReactOS leads the way with their decision to hire full-time developers

Related Articles

Lessons learned from a recent OS upgrade

Related Articles

Restore original configuration files from RPM packages

Related Articles

The 1st Rule of Discussion

Related Articles

Speed up Apache by including htaccess files into httpd.conf

Related Articles

The new amateuristic release strategy of Firefox

Related Articles

WordPress is getting better

Related Articles

How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability

Related Articles

Mozilla Thunderbird speed up

Related Articles

Why free should not always mean cost-free

Related Articles