BROWSER WARS

Yep it's a  war thats never gonna end.Iam referring to the BROWSER WARS that is taking the internet world by a storm. When i was hardly 15 i remember using internet explorer to surf through web pages that too  with a limited bandwidth. I used to take advantage of the offline view to browse data stored in cache of my system.But over the past few years internet has reached large masses mainly due to the emergence of smart phones and promotion of computers in developing nations.The INTERNET has widely evolved  since its feeble steps it took in 1985.
                                      When we think of internet , we cannot ignore browsers. A web browser is defined as an application for retrieving,presenting and traversing info in  world wide web through an URI.
As of now the current most wanted browsers include mozilla firefox,google chrome,opera,apple's safari and microsoft internet explorer.But now the competition is between two honchos mozilla's firefox and google's chrome.Even though both of them are the best, there is such vulnerability in google chrome that makes chromites as easy prey for hacker birds. I know duh that INTERNET has lost its true meaning after  30 years of  service to humanity,INTERNET is the new battleground of the nations .MOZILLA FIREFOX holds 19.26 % and GOOGLE CHROME holds 29.03 %  of usage around the world.But if GOOGLE REALLY wants to extend its reach to the common netizens, it must be able to correct these problems ..UNTIL NEXT TIME BYE BYE.

TOR BROWSERS-DEEP WEB SURFING

Tor (originally TOR, an acronym for The Onion Router, a use now abandoned) is free software for enabling online anonymity. Tor directs Internet traffic through a free, worldwide, volunteer network consisting of more than three thousand relays to conceal a user's location or usage from anyone conducting network surveillance or traffic analysis. Using Tor makes it more difficult to trace Internet activity, including "visits to Web sites, online posts, instant messages, and other communication forms", back to the user and is intended to protect the personal privacy of users, as well as their freedom and ability to conduct confidential business by keeping their internet activities from being monitored.

"Onion Routing" refers to the layers of the encryption used. The original data, including its destination, are encrypted and re-encrypted multiple times, and are sent through a virtual circuit comprising successive, randomly selected Tor relays. Each relay decrypts a "layer" of encryption to reveal only the next relay in the circuit, in order to pass the remaining encrypted data on to it. The final relay decrypts the last layer of encryption and sends the original data, without revealing or even knowing its sender, to the destination. This method reduces the chance of the original data being understood in transit and, more notably, conceals the routing of it.

As the 2013 anonymity-stripping attacks on Freedom Hosting users demonstrated, often, it is possible to attack Tor users indirectly, e.g., via vulnerabilities in servers and web browsers.

DAEMONS-WHAT ARE THEY?

In multitasking computer operating systems, a daemon (/ˈdeɪmən/ or /ˈdiːmən/)^[1] is a computer program that runs as a background process, rather than being under the direct control of an interactive user. Traditionally daemon names end with the letter d: for example, syslogd is the daemon that implements the system logging facility and sshd is a daemon that services incoming SSH connections.
In a Unix environment, the parent process of a daemon is often, but not always, the init process. A daemon is usually created by a process forking a child process and then immediately exiting, thus causing init to adopt the child process. In addition, a daemon or the operating system typically must perform other operations, such as dissociating the process from any controlling terminal (tty). Such procedures are often implemented in various convenience routines such as daemon(3) in Unix.
Systems often start daemons at boot time and serve the function of responding to network requests, hardware activity, or other programs by performing some task. Daemons can also configure hardware (like udevd on some GNU/Linux systems), run scheduled tasks (like cron), and perform a variety of other tasks.

 

CREATING PRODUCT KEYS FOR .NET APPLICATIONS

I would  suggest  using  Install key (www.lomacons.com) and Ellipter that uses  elliptical curves for  license key. A new  service called Microsoft software licensing and protection provides you with licensing options for your .NET application.

Microsoft® Software Licensing and Protection (SLP) Services is a software activation service that enables independent software vendors (ISVs) to adopt flexible licensing terms for their customers. Microsoft SLP Services employs a unique protection method that helps safeguard your application and licensing information allowing you to get to market faster while increasing customer compliance.

http://www.microsoft.com/slps/

SETTING UP ANDROID SDK IN UBUNTU

                                     

Introduction

The Android Software Development Kit (AKA SDK) is a software suite for the Android mobile operating system that allows you to write applications for Android in the Java programming language. Most people who use the Android SDK either develop applications for the Android operating system OR they use it for other purposes, such as obtaining elevated privileges on an Android device with the help of third-party software or use it for diagnostic purposes in case of malfunctioning.

The vast majority of Android users probably won't have to make use of the Android SDK, however, it is useful if you wish to learn more about the Android operating system and even then it's still a handy tool to have in case something goes wrong.

This tutorial covers Ubuntu 10.04 Lucid Lynx onwards. For anything prior to Lucid, you will have to find it yourself.

Preparation and Installation

Before we set up the SDK, we have some preparation to do. Due to some major changes in the Android SDK made in the last couple of months, setting up the Android SDK is not as easy as it was two years ago, when Android was starting to take off. Setting up the SDK itself is relatively easy once the preparation has been done.

Downloading the SDK Starter Package

First things first, we have to obtain the starter package. The SDK starter package can be obtained at http://developer.android.com/sdk/index.html.

Download the one for Linux (.tgz file) and once it's finished downloading, extract it to somewhere safe and easy to reach. For example, the home folder. To do so, open up a terminal, navigate to the directory where the SDK was downloaded and enter the following command:

$ tar -xvzf android-sdk_rXX-linux.tgz && mv android-sdk-linux ~/

As of 12 May 2012, the Android SDK is currently up to r18, however that is set to change in the near future, and as such, replace XX with the version of your SDK.

Setting up Java

Prior to SDK r08, everything you'll need to develop applications was included on a 100-200MB .tgz archive. However, with the release of SDK r08, the tools necessary for creating and building applications was removed and can be obtained by using the Android SDK and AVD Manager which is located in the /<sdk>/tools folder.

However, you should not execute the Android SDK and AVD manager just yet, as you'll most likely get a Parse: XML error notice. The reason for this is that after SDK r08, it's now required to have Java installed before you set up the SDK. To do this, we'll download the OpenJDK and the Icedtea browser plugin. In a terminal window, enter the following command:

$ sudo apt-get install openjdk-6-jre openjdk-6-jdk icedtea6-plugin

This will download and install the OpenJDK implementation of Java, which will be sufficient enough for us to download the SDK platform tools.

Downloading the SDK platform tools

This is pretty much the actual "installation" of the SDK's platform tools. One key reason why this step is important is that it contains an important protocol called the Android Debug Bridge (ADB).

ADB comes bundled with the SDK platform tools. It is a command-line tool used to communicate with and control the device over a USB link from a computer. The tool comes bundled with the Android SDK and is commonly used for diagnosing problems with the device. Once you have ADB installed, you can use ADB to copy files to and from the device's internal memory, install apps, run commands, see logs and more. This makes it an invaluable tool if your device is running into some trouble that might warrant a new device.

Now, in order to obtain the SDK platform tools, we'll need to initialize the Android SDK and AVD Manager that I mentioned earlier. To do so, enter the following commands in a terminal. The first command will direct you to where the Android SDK and AVD Manager is located, and the second will execute said program.

$ cd ~/android-sdk-linux/tools

$ ./android

Once you do that, a new window will pop up, which is the actual Android SDK and AVD Manager. Click on "Available Packages" and you will be presented with two boxes. One is the Android Repository and the other is the Third-party Add-ons. Click on "Android Repository" then click on Install Selected. A confirmation window will pop up. Click on "Accept All" and then click on the Install button to install the SDK platform tools. It's quite a bit to download so make sure you have at least 512MB to 2GB of hard drive space available. Once the download has finished, you'll get a notice saying that the ADB daemon needs to be restarted. Click on "Yes" and everything will finish downloading.

Post-Installation Configuration

Now once the download has finished, or while you're waiting for the download to finish, we have to configure Ubuntu a little to meet our needs. First, we have to set up the PATH variable to include ADB and other SDK tools, and we have to make sure our hardware will be detected once we initialize ADB.

Modifying the PATH Environment Variable

In the days before Android 2.2, a good number of people used to place their various projects and applications in the directories where the necessary tools they used existed. This was in itself a very flawed method because it cluttered up the directories, and while cleaning up the SDK, one might accidentally delete a crucial file, which will cause the SDK to fail and having to completely reinstall everything.

Modifying the PATH Environment Variable will help out immensely when it comes down to making use of SDK tools like ADB. Doing this will also allow you to execute certain protocols like ADB from ANY location. So if you're operating from the Desktop, you don't have to redirect to the SDK's platform-tools folder to make use of ADB if you need to make use of it.

Enough chatter, let's get busy. To modify the PATH variable of your system, you need to edit your .bashrc file. To do so, in a terminal, execute the following command:

$ nano ~/.bashrc

You will now have the Nano text editor enabled on the terminal. Now, at the very top of the file, enter the following:

#AndroidDev PATH

export PATH=${PATH}:~/android-sdk-linux/tools

export PATH=${PATH}:~/android-sdk-linux/platform-tools

Once you're finished, press CTRL + X, Y, and then hit Enter to save your changes and exit the Nano text editor.

Preparing Hardware

Now that we have our PATH variable set up, we need to make sure our hardware will be detected once we initialize ADB. However, up until Natty, udev in Ubuntu wouldn't allow ADB access to the Android phone via USB. This was fixed in udev version 165-0ubuntu1 — if you are running an earlier version (apt-cache policy udev will tell you whether you are), you'll need need to create a new udev rule file as root.

In a terminal, execute the following command that will create the rule file. This will utilize the graphical sudo command, so that we can still have control over the file if we're not a root user.

$ gksudo gedit /etc/udev/rules.d/51-android.rules

Copy and paste the following udev rules in the text editor that opened up which contains the new rule file we created. The rules included should work with most if not all Android devices across multiple manufacturers, such as HTC, Motorola, LGE, and so forth.

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="0502", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="1004", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="0fce", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="0489", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", SYMLINK+="android_adb", MODE="0666"

SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666", GROUP="plugdev"

Once you've copied and pasted the udev rules in the text editor which contains your newly created rule file, save your changes and quit. Now that you've set your udev rules you have to reboot so that ADB will be in your path.

To test your changes, open up a terminal and execute the following:

$ adb devices

Note: You may need to enable USB debugging mode on your phone first in order for it to be recognised.

This will give you two messages:

1) It will tell you it's initializing the ADB daemon. 2) It should show you a list of connected devices.

If all went well you should see your device's serial number under the list of connected devices. If you see a message like:

List of connected devices

???????? No permissions

This means your hardware was detected, however you made a mistake in configuring Ubuntu or the udev rule for your phone's manufacturer was not listed.