“The most unfortunate thing is that India still seems to believe in proprietary solutions. In India, open source code software will have to come and stay in a big way for the benefit of our billion people.”                                                                                                                                                     —Our Ex-President Dr.APJ Abdul Kalam

LINUX

Linux is a free Unix-type operating system originally created by Linus Torvalds with the assistance of developers around the world. Developed under the GNU General Public License , the source code for Linux is freely available to everyone.

Richard Matthew Stallman
(Founder of GNU)

Here ‘FREE’ means not only the free of cost, actually it gives 4 freedoms

# The Freedom to Use
# The Freedom to Modify
# The Freedom to Copy
# The Freedom to Redistribute Changes

Linus Torvalds
(Inventor of Linux Kernel)

Why we need Linux?

# Freedom
# Virus free
# Stability & Security
# Multi-user
# Installing Softwares becomes In SINGLE-CLICK
# No PROPRIETARY issues
# Don’t wait years to fix the bugs
# It can run for years without restarting
# Jump in to Next generation of computers
# Do something for world
# An excellent window system called X
# Supports multiple processors as standard
# True multi-tasking
# You can try Linux without touching the OS which already you have
# Get great music players
# Play hundreds of games for free
# Last but not least Enjoy free and unlimited support

How can we get Linux ?

# By downloadind from corresponding site
# By getting the CDs from your city
# By asking CDs through mail

What are all have Linux?

Here I mentioning few

(1) Server Side

# DNS Server      –    BindDNS
# Mail Server       –    Postfix
# Web Server     –    Apache
# DB Server        –    Mysql
# File Server       –    NFS & Samba
# Print Server     –    CUPS
# Firewall            –        IPTABLES
# Proxy Server   –    Squid
and many more…..

(2) Development Side

# GUI related
* X Window System
* GNOME
* KDE
* Xfce desktop environments
# OpenOffice.org for office suite
# Mozilla for Firefox for web browsers
# Thunderbird email client.
# Typesetting and document preparation systems
* TeX
* LaTeX
# Graphics tools
* GIMP raster image editor
* Inkscape vector graphic editor
* Paint.NET raster drawing program
* Blender 3D animation program
# Text editors like vi or emacs.

Some Linux Distributions

# Debain based distros like ubuntu

# Redhat based distros like fedora,centos

# Mandriva based distros like mandrake

LUG (Linux User Group)

A Linux User Group or Linux Users’ Group (LUG) is a private, generally non-profit or not-for-profit organization that provides support and/or education for Linux users, particularly for inexperienced users.

For our city  it is ilugc , which is doing some great works here.

The Ruby on Rails framework is an open-source web application development framework developed initially by David Heinemeier Hansson. Ruby on Rails is written in the highly-dynamic open-source object-oriented Ruby programming language, developed in the early 1990’s in Japan.

Powerful and Simple

Ruby on Rails questioned prior assumptions and opened up a new way to create web applications that emphasized simplicity and productivity.

Developing in Rails means:

• a lot less code
• a lot less configuration data
• bringing up basic functionality quickly
• building out new functionality incrementally
• integrated testing

Advantages of Ruby on Rails

1. Don’t repeat yourself(DRY):

Every element of the web application has its specific place and doesn’t have to be repeated multiple times across files.

2. Convention over configuration:

By using practical conventions, most configuration data can be eliminated (however the conventions can be overridden with configuration when necessary).

3. Quick turn-around time:

By providing an integrated web server and an interpreted language, the results of code modifications can be seen immediately, thereby minimizing the code-debug cycle (with no additional compile step).

4. MVC architecture:

ruby on rails is based on model view controller architecture that helps in dividing the whole application into layers

Separation of business logic from database logic and from user interface is handled cleanly, decreasing coupling and providing the benefits of orthogonality

5. Active Record:

The core concept of Active record and other object relational mapping libraries is that relational database can be represented reasonalbly in object-based code if you think of database tables as classes,table rows as objects, and fields as object attributes.

6. Single-stack application framework:

Ruby on Rails includes all the components necessary to build complete web applications from the database forward (even including a pure-Ruby web server for those who wish to develop immediately without setting up a web server such as Apache or lighttpd), providing object-database linkage, unit and functional testing tools, stylesheets, support for multiple templating systems, multi-environment deployments, support for automated local and remote deployments (via the included Switchtower utility), inbound and outbound email support, web services support, etc.

7. Database agnosticism:

Rails supports a wide array of databases, including all the common production database platforms. Developing, testing, and deploying Rails on multiple databases simultaneously is very successful.

8. AJAX UI support:

The most viable technology for streamlining user interaction is AJAX (“Asynchronous JavaScript and XML”). Ruby on Rails’ support for AJAX is powerful, flexible, terse, and well-integrated into the framework. The development of the Prototype AJAX library (a popular AJAX and JavaScript effects library) has been driven by Rails development feedback.

9. Integrated unit and functional testing support:

Testing in Rails is simple, well-documented, terse, and integrated into the Rails framework. Rails builds the necessary scaffolding for unit and functional tests automatically, and tracks test/code ratios automatically. Rails includes native support for mock object testing and database fixtures, streamlining out-of-container testing.

10. Web services support:

Rails supports the most popular web services protocols, including XML-RPC, SOAP, and WSDL. Rails’ flexibility with regard to external APIs enables addition of further web services interfaces easily. The popular Rails weblogging software Typo serves as an open example of the ease with which new APIs can be added to Rails applications.

Occasionally a site user or developer will navigate to a page and suddenly the page content disappears, and is completely blank. No content. No errors. Nothing. This is what is referred to as the White Screen of Death or WSOD.

Work around for this problem is to add the following in beginning of PHP code:

ini_set(“session.save_handler”, “files”);

The “save_handler” is just defined in php.ini with value “files”, redefining the save_handler before calling session_start() solves the problem.

Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable but difficult to implement.

Single sign on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign on. For example, an environment where users are prompted to log in to their desktop, then log in to their email using the same credentials, is not single sign on.

As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.

Benefits of SSO:

* Reduces phishing success, because users are not trained to enter password everywhere without thinking.
* Reducing password fatigue from different user name and password combinations
* Reducing time spent re-entering passwords for the same identity
* Can support conventional authentication such as Windows credentials (i.e., username/password)
* Reducing IT costs due to lower number of IT help desk calls about passwords
* Security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users
* Centralized reporting for compliance adherence.

SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users do not actively have to enter their credentials more than once.

Enterprise single sign-on

Enterprise single sign-on (E-SSO) systems are designed to minimize the number of times that users must type their ID and password to sign into multiple applications. The E-SSO solution automatically logs users in, and acts as a password-filler where automatic login is not possible.

Some E-SSO solutions focus on delivering quick return on investment and shy away from requiring complex infrastructure hardware additions. These solutions are generally software-based agents which roam with the user and automate the process of login and password change for the desired applications (Win/Java/Ajax/Web/Terminal Emulator). The benefit of this approach is that users can have any username/password for the target systems/applications because from the E-SSO agents perspective they are all just ‘credentials’ to store. Given that user credentials may be cached locally (and sync’d to a central repository) the use of strong encryption as well as reliable and viable key recovery options are suggested for the chosen E-SSO technology.

Ideally, there is no need for the users to actually have a first hand understanding of their assigned credential(s) for end applications after implementation of E-SSO, and as an upside once users have confidence in this way of thinking application owners are encouraged to increase password length and complexity such that the user could not easily remember the password on their own.

There is also a significant security upside with client side E-SSO solutions. Given that the user’s credentials are now stored in a very secure cryptographically locked store and that the users themselves no longer know (or care to know) the applications credentials, it’s possible to ‘release’ (logon with) certain credentials based on a defined ‘authentication grade’. Two factor authentication systems such as smart cards or biometrics can be linked to different authentication grades. A user might for example have 10 sets of credentials in their encrypted store, for 10 different applications. Applications 1 through 6 might simply require that the user has shown to have successfully logged in to the primary domain (i.e. Windows Active Directory, etc) but when the E-SSO client goes to log on the user to applications 7-10 it might check for the insertion/presence of a smart card with valid user keys on it. By doing this the enterprise has effectively implemented two factor authentication but have not had to deal with the challenges of back-end infrastructure additions/application modifications, etc.

With client-side E-SSO solutions enterprises can very easily transition from a regime where passwords are easily brute forced and authentication is single factor to a scenario where high yield applications are now two factor authentication access controlled, passwords are complex and users don’t know them, hence hackers cannot effectively brute force applications with dictionary or rainbow tables.

There are lot of factors that contribute to a success of a software application. It is common to think of an application having no errors, but literally any application may be having few to more errors in a given point of time. Though it is a good feeling to know the fact that a given application doesn’t have any errors, which is very hard to achieve. There are different kinds of errors like design errors, programming errors, etc.,. As the name indicates design errors should be found out and resolved during the application design phase, which is most essential for any good application development process. The next main focus should be on programming errors. Programming errors are logical errors which should be handled effectively during the coding phase of any application development process. Coding errors may be hard to find out and resolve. Hence it is very important to ensure that the coding phase is carried out in a very efficient manner, with multiple levels of review about in the coding phase itself. This would eliminate major coding errors. This article describes ways and best practices that should be followed in any application in the area of ‘Error handling’. Though this article will be more inclined towards the Java technology, this is also common in almost all Programming languages, especially OOP languages. This doesn’t go into the microscopic details of exception handling implementation.

Poor exception-handling implementations can spoil even the best design. There should be an agreement on a reasonable exception-handling style for your application and following a consistent set of exception-handling practices is crucial to implementing software that’s easy to maintain, enhance and improve. The longer you avoid exceptions, the harder it is to wedge cleanly designed exception-handling code into working software. To demystify exception-handling design, we must more widely accept and follow proven techniques, guidelines, and patterns.

Exception basics: An exception is an condition which occurs when a component/object ends prematurely when trying to fulfil a responsibility. As mentioned above exceptions are of different types, but on a general perspective an exception is an indication that a part of a program has encountered an error situation. Exceptions can be broadly categorized into two, one is the ‘Exception’ itself, which can be usually caught/thrown/delegated in a way the programmer intends to do it. Uncaught exceptions are generally caught by the runtime environment and are thrown to the caller. One more type of exception is usually referred to as ‘Error’ which is not usually caught by the user programmatically, this is an unusual condition which is naturally dealt with by the runtime environment.

Exceptions can be further categorized into two types, one is compiler exceptions, where the compiler enforces a rule that these exceptions should be generally caught/thrown in the program. This general rule is enforced because it is a way to indicate to the programmer that this exception can occur, hence program a possibility to handle this in case it occurs. The next type is runtime exceptions, this can also be referred to as programmatical errors which should be resolved during the coding/review phase, if not, atleast when unit tests are carried out.

Few general rules to remember/follow while dealing with exceptions:
1. Don’t try to handle coding errors.
2. Limit Declaration of custom exception classes.
3. Name an exception class with reference to the error cause and not with reference to the origin of the exception.
4. Provide more details about the context along with the exception.
5. Handle exceptions as specific or close to the problem you can.
6. Use exception handling only to signal emergency situations.
7. Don’t re-throw the same exception.
8. Last but most important is Log your exceptions, use a application logger utility.

Though this article seems to be a short one, it covers a lot of ground in reality and gives a high-level description of most of the areas in Exception handling.