As the new version of Microsoft Windows 7 is nearing completion, many users are gearing up for the big upgrade. Since it is the most popular operating system, many people who use an alternative OS miss out on some good software made for Windows, such as Photoshop, many new games et cetera. Even though we have partial solutions like Wine, they are not perfect and remain the main obstacle for wider adoption of open source operating systems.

The ReactOS Team gathered more than 10 years ago to address this problem. I often wonder why they fail to make the headlines with their releases (probably because the project has yet to reach beta stage), as their goal is very useful to the wider open source community: to completely reverse-engineer Redmond’s flagship product, thus providing a working clone of Windows under an open source license. 10 years is a long time and although they failed to deliver version 1.0 in this time, by working closely with the WINE project, they managed to put together a working development version, which is still impressive considering the work reverse-engineering a multi-million-dollar project demands.

I know I’ve written about the project before, but I never did an extensive review. I decided to do it this week, the guys are doing a great job and they certainly deserve a mention.

So let’s see what version 0.3.9 has in store for us, shall we?

The new release is very fast, the minimum requirements are under 32 megabytes of RAM, you will need as many megabytes of hard disk space to download the live image. I took 0.3.9 for a spin using Virtualbox. The LiveCD should work fine too.

Apart from the usual apps and a skin that will make any veteran Windows 95 and 98 user shed a nostalgic tear, the Tango icon theme certainly improves the overall impression. Notice the icons do not have a transparent background. I believe this is a Virtualbox problem, it worked fine using the LiveCD. And what do we have here? Virtual desktops! Yes, ReactOS provides this essential tool out-of-the-box (unlike Windows 7).

ReactOS also features ReactX, which should replace DirectX. It is still in its early stages, but you can see it resembles DirectX very closely, even with the version numbers.

Now let us download some applications! First, we will try out ReactOS’ “Download”, an interface similar to Linux package managers. You simply select the software you wish to install, and the front-end does the rest of the work for you.

Not really a lot of apps available yet, but there is some fun stuff, like Diablo. I downloaded DosBox, Abiword and Firefox (both 2 and 3 are available). Don’t forget, these are all Windows binaries!

The installers worked fine. Now to try the software out!

Firefox 3 was a minor disappointment. Looks like it could not render the CSS. On the other hand, it did actually load the sites. And because there are lots of nice plugins like FireFTP which can replace some desktop apps, making Firefox work well would be a step in the right direction.

I then attempted to run Abiword, a FOSS word processor. In the virtual machine, there were some graphics glitches, but I could write without any problems. The toolbar buttons were a bit funky, too.

So the tested applications managed to run and perform some basic tasks. Even though ReactOS is still in alpha, let us try some untested software and see how it works. I fired up Firefox, downloaded the VLC player installer…

… when suddenly …

You have to admit this is a good Windows clone. Joke aside, I am sure this will see a great deal of improvement throughout the alpha and beta stages.

Since the restart takes about 20 seconds and I was still curious, I rebooted the VM and downloaded the lightweight OffByOne browser (interesting that they included it in Downloads) in order to obtain my VLC executable. This is how the ReactOS File Manager looks like. Like Explorer’s evil twin.

I installed VLC, but sadly it did not run. Of course, I was maybe wrong to choose a multimedia application, though I somehow had confidence in VLC’s excellent programming. However, this is still an alpha-quality operating system and multimedia is probably not their first priority.

I recommend you give ReactOS a try. You will be surprised at how far a community project can come. Programming an entire operating system is not an easy task. The ReactOS Team certainly has the vision, they want to bring you a completely free version of Windows, so you have control over what you run, but do not need to switch to an OS that works different. ReactOS gives you a choice and choice is one the most important aspects of software freedom.

You can view the project roadmap here and if you really like what they are doing, consider donating a few bucks. To download and test ReactOS click here.

I received another guest blog article, so I’m posting this before I start. This very interesting article is by Ryan. Ryan’s other postings are at http://source.kohlerville.com where he mainly posts about problems he runs into at his work.

At my work, I noticed that I work on some documents that I felt needed to be encrypted. Working in a hybrid environment with Gentoo Linux, CentOS Linux, Solaris 10 sparc/i86pc, and Windows, I wanted to pick a program that was open source and can use cross platform if possible. I wanted to encrypt files instead of creating encrypted volumes that I have to mount and then put files into. It gives me an option to e-mail the encrypted files as well.

By default, our Solaris boxes come with /usr/bin/crypt which I can use to encrypt and decrypt files. Looking over the wikipedia entry, it is too cryptographically weak that it could be brute forced. After reading about this, I wanted something that uses the Rijndael cipher, which is much stronger and would take quite awhile to brute force.

Upon my search, I found two different open source programs that hashes the key to 256 bits (2^256 different possibilities):

• ccrypt
• aescrypt

Here’s a quick run down of some pros and cons of each:

ccrypt

Pros:
• Can be compiled/installed on multiple operating systems. Encrypting a file on Linux doesn’t mean it has to be decrypted in Linux. You can use encrypt in Linux and decrypt on Solaris just fine.
• The encryption writes over original file so you don’t leave any plain text copies around.
• The ccat command lets you cat the encrypted file to your screen without leaving plain text copies.
• Can decrypt old UNIX crypt files.
• A ton more options you can do. For example, recurse through directories.

Cons:
• The Windows port needs to have cygwin installed.
• Compiling on UNIX required to do the old ./configure, make , make install. Only a con because of how simple aescrypt was.

aescrypt

Pros:
• Can be compiled/installed on multiple operating systems. Encrypting a file on Linux doesn’t mean it has to be decrypted in Linux. You can use encrypt in Windows and decrypt on Solaris just fine.
• Windows port integrates with the context menu. You can right click a file and choose “AES decrypt” or “AES encrypt”.
• Really simply to compile, just a simple make.
• Has a java library to use for your java programs.

Cons:
• Encrypting a file creates a new file with the extension aes and leaves the plain text file alone.
• Only decrypt and encrypt, no nifty ccat command like in ccrypt.

The real deal breaker to some people though is how aescrypt can integrate in the context menu in Windows while ccrypt has to use cygwin to get it to work. I did not fall into this category as my deal breakers were the convenience of having ccat to quickly look over a file and the fact that I don’t have to do an extra step of deleting my plain text file after encrypting to be well worth it. Yes, it would be nice if I could use ccrypt in Windows without cygwin, but having it work on Linux and Solaris was good enough for me.

Choose what you need for your environment though, not everyone’s needs are the same. For creating some encrypted volumes, try out True Crypt.

Just a short notice for my readers (both of you), who still check my blog for new posts. Exam season is almost over, so expect new articles in the next 5 days!

Also, I added my blog to the Linux Outlaws Planet, a feed mashup featuring numerous excellent blogs from people in the Linux Outlaws Community. Be sure to check it out if you like Linux- and related blogs.

-gregor

This guest post was written by Jezra. You can find out more about him and his projects at www.jezra.net

Everyone keeps talking about “cloud” computing these days, and there seems to be a lot of concern regarding security and privacy of data. For those that are new to the subject, cloud computing typically involves using web-based application instead of native clients and using an external server for storage of documents. A good example is Google Docs: an online service that lets one edit documents using a web-application and the edited documents are stored somewhere on Google’s server, where who-knows-who is doing who-knows-what with the documents. The same can be said for most online services that host sensitive data.

With the “cloud” it is now possible to use a web browser to edit documents, check email, read blogs and forums, send instant messages, and do a bunch of other crap, albeit on someone else’s server, and all the end user needs in order to access all of these services is a small portable wifi enabled device; like a netbook. But what if one doesn’t want their data on someone else’s server? The answer of course is for one to run their own server at home.

When most people think of a web application server, they think of a giant energy consuming work horse that cost thousands of dollars to purchase and costs hundreds of dollars to run. However, since web apps, with fancy interfaces and boat loads of javascript manipulating the DOM, rely upon the power of the web browser’s machine, one can use an energy sipping low power machine as their own personal cloud. With a properly configured router, one can access their home network cloud from anywhere in the world (as long as they have internet access).

As long as one controls their own data, there is no reason to fear the cloud.

The guest author of this article is Morten Juhl-Johansen Zölde-Fejér.

He is a Danish public administrator, linguist, Slackware user and free culture enthusiast.
Find out more at technographer.net

A hot topic lately in the US technology media has been the discussion of the right to access the source code forming the basis of the software included in breathalyzers. Citizens accused of drinking while intoxicated have demanded access to the source code for the device in question, the breathalyzers that present the primary evidence against them in the accusation.

The request raises some issues. On one hand, the device – the Intoxilyzer 5000EN – is employed by the police and should as such be subject to scrutiny by the public. On the other hand, the company behind it is a private entity which reserves the right to deny access to the software source on the basis of trade secrets apparent if the code is made public.

Unfortunately, the debate has been somewhat obscured by a sidetrack into an open source versus proprietary software issue. While this is understandable – and more on that later – it is not actually a question of signing over the rights to the code, but simply to allow perusal of the code to ensure that no-one receives an unjust verdict. A commenter on Ars Technica posting under the name xoa suggests that it is unacceptable that this type of device is a “Black box”, an undocumentable analysis engine, and that all such devices should be developed openly and source should be placed in the public domain for inspection.

It is hard to come to an end-all conclusion on this discussion, since it squares a company’s private property against a public demand for – and right to – insight in a technological process which has the potential to influence many lives. But the discussion is important.

Interestingly, as an aside into the open source discussion, Eric Raymond argues in his classic work on the open source development model The Cathedral and the Bazaar that it is in the interest of the company – he mentions as an example producers of graphics cards – to release the driver source code, since this partially outsources the development of the driver and makes little influence on the development cycle, since by the time the competition has been able to reverse engineer the product, the producer will have moved on the next generation of the product. While I am no expert on breathalyzers, I suspect that the breath analysis market is somewhat different from the graphics cards scenario.

But the discussion is relevant, as has also been made clear by the debate around electronic voting machines. The potential for a democratic deficit is a very real and relevant concern, and it should not be dismissed. Contrary to the breathalyzers, the customer base here is clear – and in this case, it is the right (but perhaps not immediately apparent to be in the interest?) of the consumer, the state, to be able to submit the source code for review along with the election results. This is not much different from a right to a recount of votes on paper. In this otherwise technologically advanced country, a pencil mark on a piece of paper remains the method of choice for the citizen’s submission of a vote for referendums and public elections – to avoid the black box, the mystery method, between the voters and the result.

Something similar can be said to apply to medical equipment, but this is the (mine) field of patents, secret methods and methodology, proprietary software and hardware specifications locked down to an extreme extent. Still, one might argue that the source code of the software and the hardware plans of a medical device performing diagnostics or even treatment should be subject to peer review to ascertain that safety protocols have been followed and potential hazards taken into account – if nothing else, then post mortem in order to examine the cause of the fatality and to avoid further injury. Obviously, only a select few scientists would have the knowledge and abilities to assess this question, a highly specialized combination of medicine and informatics.

I shall finish off with a quote by a representative of the natural sciences, a mathematician to be more exact, who has taken the consequence of scientific accountability and, as the project leader of the free software application TeXmacs, has presented the following conclusions:

As a mathematician, I am deeply convinced that only free programs are acceptable from a scientific point of view. I see two main reasons for this:

• A result computed by a “mathematical” system, whose source code is not public, can not be accepted as part of a mathematical proof.

• Just as a mathematician should be able to build theorems on top of other theorems, it should be possible to freely modify and release algorithms of mathematical software.

However, it is strange, and a shame, that the main mathematical programs which are currently being used are proprietary. The main reason for this is that mathematicians often do not consider programming as a full scientific activity. Consequently, the development of useful software is delegated to “engineers” and the resulting programs are used as black boxes.