SVN Error: Unknown command 'lock'

For above error update SVN client to SVN 1.2 or above.

Apache Installation with SSL: no OpenSSL headers found

If you get above error that means apache was not able to find the opensssl C header files for compiling withs SSL. First of all make sure you have OpenSSL installed on your machine, if not please install it. If you openssl installation is not at standard location then use --with-ssl=/path/to/your/openssl option with apache configuration.

My openssl was in /usr/local/ssl, which seemed to be standard location, but it Apache did not recognize it, I guess because it expects it in /usr/local/openssl. Anyways following worked for
./Configure --enable-ssl --with-ssl=/usr/local/ssl/

Open SSL installion issue on Solaris

I was installing openssl-0.9.7 on solaris when I got following error:
cc1: error: invalid option `arch=ultrasparc'

This was very strange, I googled but could not find the answer. Then I checked the operating system details, and here are the details:
uname -m --> sun4u
uname -r --> 5.9
uname -s --> SunOS
uname -v --> Generic_118558-28
gcc -v --> 3.4.6
I was using default ./config for installtion, which was selecting solaris-sparcv9-gcc as os/compiler flag. It assumed since i am using gcc version > 3.0 it would recognize -march=ultrasparc option. But since my compiler didn't understand that, I used following command.
bash# ./Configure solaris-sparcv9-gcc27
This forces it the config to not use the -march... option. So the above error disappeared, but resulted in one more error: 'ar command not found'
This time solution was easy, I just added /usr/ccs/bin to the path and it worked.

HTTP Redirect : Do it the right way !

There are two ways to redirect a user to a different page:
A) Server redirect : This is where server notifies the client in HTTP Response header that the page has been moved somewhere else. This is done by sending one of following response status code in response Header

• Permanent Redirect (301)
• Temporary Redirect (307)
• Undefined redirect (302)

Here client do not need to get the body of the response before redirecting. In this method when a client contacts server for a document the server itself, configured to redirect the document to another address, replies to the client that it should instead look at the new address. Examples:
JSP/Servlet: response.sendRedirect("PATH_TO_NEW_RESOURCE");
Perl:
print "Status: 301 Moved Permanantly\n";
print "Location: PATH_TO_NEW_RESOURCE\n\n";
Apache mod_rewrite:
rewriteEngine on
rewriteRule OLD_PATH PATH_TO_NEW_RESOURCE [R=permanent,L]

B) Client redirect : This is done in HTTP response body as opposed to the HTTP response header. This can be done either by HTTP META Header tag:
<META HTTP-EQUIV=REFRESH CONTENT="1; URL=PATH_TO_NEW_RESOURCE">
Or using JavaScript:
<script type="text/javascript"> window.location.href='PATH_TO_NEW_RESOURCE'; </script>

Here the client need to download the full body of the response, look for refresh instruction or Javascript code block and then proceed for new address.

Clearly you should use Method A (Server Redirection), Disadvantages of using Method B are:
1) It causes Browsers to flickr and refresh as the old page is loading.
2) The Meta tag could really break the Back button, You would have faced this problem with many pages, after clicking the back button and it keeps coming to the same page. Braking the back button is really a sin from UI design perspective, it is the second most used browser feature and you don't want to break it. User can get really annoyed with this, close the window, and may not visit your site.
3)The HTTP status code of the page will remain 200, most search engines will continue to think the location is valid. Any page rank of the old location will not be transferred to the new location.

Moreover in Method A the server also gives some information about the purpose and type of redirection, which allows the Client to behave differently depending on the type of redirect (302, 307 or 301).

Android Vs. OpenMoko

While microsoft is continuing to annoy users with enforcing new Vista OS for PC, which sucks big time. Other players are clearly seeing future in Mobile phone. While Apple iPhone is clearly the winner currently, Google has launched Android and has got a lot of media attention, even though the first working phone is not available yet. Though Trolltech's Qtopia GreenPhone and Openmoko could not get such the media attention, but they are worth mentioning.
Future of GreenPhone doesn't look so green to me, but Openmoko will go a long way. They have recently open sourced the CAD files for NEO handset. So with Openmoko you can pretty much create your own cell phone. While this sound good for geeks, it might not be so attractive for end users. A normal consumer would want a well finish product, and some branding too. Here Android has a unfair advantage over Openmoko.
With $10 million prize tag, Android is bound to get lot of innovation from developer community. So innovation, Google Brand, backing of Open Handset Alliance may well get Android platform way ahead of competition. But it will be interesting to see how Apple reacts to Android challenge. I don't have much expectations form Windows Mobile and Symbian.