4 Long weeks

I am in a mood to write something tonight, after long 30 days, m back in Bangalore – crackers r bursting outside – of course not in my welcome – but because people still have Diwali hangover..

If I look back now, it seems as if it was yesterday when I was asked to go to Japan, there were few questions in my mind, how safe it is, it will gonna be really challenging, long working days/nights and food will be a challenge along with language – but somewhere had the confidence – ki sab ho jaayega…

& the journey started….

Reached Singapore, and I had 60 mins for next flight, I thought wow airport is cool, let’s explore it, I knew my flight is from next terminal, I thought I’ll be there in few minutes big deal!!

Wooo, it took me 15 mins in sky train (quite an experience) – to reach to next terminal and flight was from gate 51 odd….gosh!! took another 15 mins to be there….just managed in time!! – first lesson learnt – better be on time – come out of Indian time zone J

Air-hostesses were coolJ, polite – hot & humble…lolz. Suddenly all the faces in the airbus were so different and I already started getting a feeling of “welcome to japan” – 7 more hrs and we landed. Extremely well organized , strict adherence to queuing culture, I started hunting for information desk to get pointers to hotel…

Took the train – hopped around on another one mid-way and finally reached hotel, initially train map looked like some puzzle – lines of difference colors intersecting each other at every second point but after a close look of 5 mins – it seems to be really easy to understand – Lesson 2 :- Things aren’t that complicated as they are projected – keep your cool and things will fall in place J

Hotel:-

Nothing much to say about the size of the room, the bathroom in UK was bigger than the entire room, nevertheless I accepted it happily as I had no other choice but to do that J

Iron table, funny creation – I still don’t know – how to open that, TV which I never turned on, however it’s manual was full of porn stuff – dial this – for this girl, this for this show…blah blah blah…!  - comeon we aren’t in college – grow up hotel people – stop sharing this naughty stuff J

Office was around 20 mins walk from hotel, sometimes I walked, mostly I took bus – one thing which I still don’t understand is  dressing sense of girls…

Top – as tight as it can get

Skirt – as short as possible

Shoes – as long as it can get (it covers everything, what ideally skirt is supposed to do – may be perfect combo of team work)

Anyways, I always enjoyed my journey on the way to office (that’s the only time I could see some people, I generally use to come around 2am, 4am sometimes next day from work – so never had chance to see the crowd on the way back…

They have musical end to every word – and they do get surprised pretty easily - operating their ticket machine was quite an experience as everything was in Japanese. Had toughest of times while shopping in super market, nothing is written in english and to add to it – only 0.01% of entire stock will be pure-veg. If you are veggie like me – be prepared to loose few kg’s J - the prices are crazy, it’s so very expensive – you just can’t convert anything to INR. You need lots of cash to survive here.

Covering work related aspect quickly:-

Overall I am happy and satisfied with my contribution, couldn't have think of any better, lots of positives to take forward and felt nice as lots of big shots appreciated. 17hrs per day without break for 30 days was a bit too much (but I enjoyed every moment of it, and gave more than 100%). it was quite an experience meeting people from different parts of the world working towards one common objective.

Earth quakes:-

First one – I got bit scared, stood up – looked around – was waiting to copy whatever others are doing, guess what they did nothing – they just ignored it.!

Second one:- I remained seated, looked around with caution, no prize for guessing –everyone ignored it again.

Third one: - Guess what – even I ignored it this time!! - remained glued to my system!

One think I did pretty often, after 17/18hrs when I use to come back to hotel – first thing – go to the bath tub – lie down take a long hot water shower – cant express how much I loved it and find it really refreshing….

Breakfast:-

Out of 28 coupons, I still have 20 with me J - which means I had breakfast 8/28 times, reason – nothing to eat there for me, only juice and bread-butter and their special timings 6.30 to 7.30 (no way u can get up by 7, if u have slept at 4-5…)

I survived mostly on ready to eat, fruits, coke, lemon juice, curd & pizza.

Pizza ;- there is a small story about the famous Japanese pizza, I went to the supermarket and when I was 100% sure – it’s pure veg, I opted for it and while heating it in microwave there was a small sachet along with pizza, which I thought is topping (something stopped me from within) and I decided not to use it, I tasted a bit – it was yuck – I threw it in dustbin and next day I got to know – that was poison to keep the pizza fresh…..i was like What the f*$% – why in d world will someone put the poison next to pizza to keep it fresh, later I got to know – it’s pretty common, that day onwards – no experiment’s, stick to what you know and eat that only!!

After 22 days, I got a day off – for the first 2 hours – I kept wondering – what to do….and I was finding it hard – that I have entire day for my own self, I covered as much as one can think off, clicked hundreds of pictures and uploaded everything on fb, shopped a lot for everyone and it was great fun. Visit to traditional temple, went for the cruise for the first time in my life, followed by walk on lonely rainbow bridge, quite a romantic place, saw few couples doing naughty stuff ;) – nice to see this part of Japan.  I did got 4 calls from office, but no one asked me to come over  - so I ll still take it as an day off J

Same old life started from next day, and as the time of departure starting coming closer – work started piling up, I wanted to finish everything properly before I make my way back, I realized I still had lots of ready to eat packets left with me, so I hosted a lunch …authentic Indian lunch for my gang (people who were sitting around me) – they loved it, worked complete – compiled and it was the time to capture some bye-bye moments with people I worked with.…

Off to Singapore:-

I had 18 hrs of transit, and I had no idea, what will I be doing during those 18hrs, I was still hopeful I will get a visa (somehow) and will get to see some places, 4am in the morning, after 15 minutes of discussion with immigration office – I got the green signal and visa is done J - I should have waited for 3 hours as I realized moment you get out of immigration zone, there was no internet, no proper chairs n absolutely no facilities L , had to spend next 4 hrs in really difficult conditions, counter opened at 6 – I picked up all the maps – and was so happy to find information in english…

First train was at 7.30, I took ticket to last destination and started hopping in and out of their stations, covered quite a lot, more than my expectations and again clicked quite a lot. 1^st impression – it’s a copy of London…

Singapore flyer is ditto like London eye

Orchard street is subset of oxford street

Marina bay is like a bay on river Thames…

From there it was a journey to my friends place, met his family and had nice Indian lunch, off to airport and was all excited to board the flight to Bangalore. Out of all the flights I had taken till date, this was the first time a girl was sitting next to me, well I had not slept for 2 nights, so I really wanted to catch some sleep – all I remember Is she was from infy…slept! – When I woke up – I was in Bangalore.

Felt happy to be back – reached home around 2 and next morning at 9 – I was in office…

I am still having a bit of hangover of Japanese working style, I still get up at 4.30 in the mornings (3.5hrs delta between time zones),  I think I will take some time to get back into normal mode of working..

These days 90% of office is on vacation and m still working L, looking forward to 2^nd of nov when my mother will be back.

Overall – quite an experience – lots of learning’s – never felt so close to customer and never realized contributing that closely to end product…experienced a different side of culture – lots to learn from them – respect, care, concern, ready to help attitude even for a stranger, punctual and well mannered.

But along with this – sometimes it’s good to break rules and have fun – thodi masti bhi zarori hai yaar.. Never loved the Bangalore food so much before, everything tastes WOW now, I cherish lots of things now which I generally use to take for granted before J.

Really looking forward to my next match, it’s been almost 80 days since I played last- longest ever break in my career of 15 years…

I think it’s enough for today.

Signing off from my bed :)

Sahil

27.10.2011  11.00 pm

Life in Tokyo... :)

In next few minutes I am going to write whatever comes to my mind randomly about my experience of last 20days in a Tokyo.

Let’s start from Airport, well organized, everyone strictly follows queue culture and staff members are more than willing to help you but language does play a trick. I couldn’t even think about taking Taxi to Hotel as rates were crazy, 100$ from Airport to hotel was way too much, I explored other options and got a 10$ deal by train, which I had to change half way to catch another one, again rail system is well organized, well maintained and this country is extremely punctual. People are humble, polite and are always ready to help. They do have a bowing culture which they do to signify the respect towards other person. Once I reached hotel, I was amazed to see the size of the room, I remember bathroom in UK was bigger than the room in Japan. Anyways I had to spend 30 days in same room, so I happily accepted it. Just like any other hotel room there is a TV (which I never turned on for couple of reason – I never got time to even look at it and secondly It has all Japanese channels), then there is an iron table which doesn’t open or maybe I don’t know how to operate it. From the window of the room I can see the entire area, which always reminds me 'this city never sleeps, I repeat never'!

  I have come back from work sometimes at 3am, sometimes at 4, 5 and once even at 6am, I have always found people on road, having headphones on and busy in their own world. Coming to work – well I would say it’s really different, though I was quite prepared for it, before I started form Bangalore a special person had told me before you start any-work – be sure of what you are doing, set goals, ask questions and be very sure of what you do and then proceed further, I kept this mantra in mind and if I look back now after 20days, this is the thing which has helped me a lot more than anything else. It’s a different culture, different working ways, things sometimes that look so obvious – aren’t that obvious. Language is a big barrier and does play a trick. You need to stay calm, focus entirely on work – don’t get carried away by earthquake shocks or long working hours. On an average I work for 16hrs at office and then 1-2hrs from hotel, but there were many occasions where I stayed back for 22hrs and once I did crossed one cycle of clockJ. People here are really hardworking but there is something missing, “sometimes you do feel this is not the best way of doing this, it could have been done this way to save lot of time” – but here the culture is bit different, once if something is followed –its followed! – No questions after that unless it comes from top. After putting in such long hours, I did slept few times with shoes and specs on J and I don’t remember when was the last time I slept for 6 hours!!

Coming to food, if you are a vegetarian, this country is not meant for you, I have completely forgotten how a fresh cooked vegetarian food tastes, I am surviving on ready to eat, coke and fruits. Yes I did lost 3kgs already In less than 3wks and it’s so very expensive in the city, best is never try to compare when Indian currency just happily keep moving and spend. I could never take meals on time, and I did skipped lots of them (I know it’s not good but I could never really think about it, was so indulged with activities).

17^th day was special, after 16 long , really long days,I got half a day off,where I went with my colleague and roamed around whatever we could,if you have worked like this,you are bound to love everything you see, so we clicked a lot and uploaded everything.Life was same from next day but that break did refreshed a bit,but half a day suddenly disappeared in few mins.

With last few days to go I am planning to do as much as I can to bridge the gap which will help in future, and i am quite happy to receive a compliment from my colleague who was here for few days, he told something special about my work- which meant a lot to me. Coming to personal side, when I just want to purchase something for my mother, wonder when will i get a chance, may be on the last day I could visit some station (oh, I forgot to mention, here stations are huge and each station has big shopping complex of few floors, their marketing concept is maximum people commute by trains so it makes sense to have station cum mall kind of complex). So hopefully I will get something from station, generally whenever I go back to hotel I couldn’t find the shopping complex open(it closes at 11), and morning it opens at 9 and I generally leave every day before 9. But I will surely get something for her and something for my colleagues back in Bangalore – Japan special.

To summarize, well I would say I was fortunate to get this opportunity and I had a very different experience, learnt a new side of culture and different working aspects, had best week when my colleague from UK was here, learnt a lot from him and yes did made some new friends at work and I am sure it’s just the beginning of the journey!

I will pen down again, don’t know why, but I am not getting sleep today. I didn’t had anything else to do – so that’s how this write-up is created!


Proper blog will follow someday!!

Sahil Gupta

Kokubunju-Tokyo

Japan!

Kernel.org is hacked, what'z the impact??

All open source lovers got a shocker when they came to know that kernel.org is hacked, there was some panic and lots of questions started floating on open source forums, here is a compiled draft on the news and the progress so far, would like to share with the readers:-

As recently announced on www.kernel.org, the main kernel.org server (known as “hera”) was recently compromised by an unknown intruder. The hacker was able to gain “root” access, meaning they had the full run of the system. There is no need to worry about the integrity of the kernel source or of any other software hosted on the kernel.org systems.

Kernel.org is, of course, the home for the Linux kernel. Many other projects live there as well. On the face of it, that would make kernel.org a tempting target for an attack. What self-respecting cracker wouldn’t want an opportunity to place some special code into the Linux kernel? Such code would, over time, find its way into millions of machines worldwide. The injection of backdoors or other malware is a concern for any software maintainer - open source or otherwise - but it turns out that we are well protected against that sort of attack.

If kernel developers worked by shipping simple files of source code around, they might well be vulnerable to malware added by an intruder. But that is not how kernel development is done. The code for the kernel (and for many other projects) is managed with the “git” source code management system. And git does not allow the code to be modified by third parties without people knowing about it.

How git works?

A cryptographic “hashing function” is a mathematical formula which boils the contents of a file down to a small number. “Small” is relative; git’s hash function produces 160-bit numbers, which are quite big by normal standards - it is roughly equal to the number of atoms in the Earth. The key to the hash function is that, if the contents of the file change, the hash will change too. Creating any new file matching the hash of an existing file is not really possible; if you want that new file to look like the old one with the exception of a bit of hostile code, the challenge is even bigger. So an attacker would be unable to change a file without changing its hash as well. Git checks hashes regularly, so a simplistic attempt to corrupt a file would be flagged almost immediately.

The hashing does not stop there. For any given state of the kernel source tree, git calculates a hash based on:-

(1) The hashes of all the files contained within that tree, and

(2) The hashes of all of the previous states of the tree.

So, for example, the hash for the kernel at the 3.0 release is 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe. There is no way to change any of the files within that release - or within any previous release - without changing that hash. If anybody (even the kernel.org repository) were to present a 3.0 kernel with a different hash, it would be immediately apparent that something was not right.

If an attacker were to corrupt the kernel.org repository, those other developers would notice the next time they updated their personal repositories - something that happens many times every day. If the attacker were to simply add new patches that had not gone through Linus Torvalds’s personal copy of the repository (which is not the copy on kernel.org), he would notice the next time he tried to make a change of his own. Git will see that the hash values are not what they should be and raise the alarm.

Kernel.org may seem like the place where kernel development is done, but it’s not; it’s really just a distribution point. The integrity of that distribution point is protected by the combination of clever software and thousands of copies of the repository distributed around the world.

It will be necessary to rebuild the kernel.org infrastructure and to figure out how the attacker got in. The integrity of those systems was lost; restoring it and protecting it into the future will take a considerable amount of work. But people running Linux need not worry about the integrity of their kernels; that is protected by defenses stronger than those of any single computer.

Also as announced by Linus “ entire repository of Linux Kernel gets hosted at Github”

Here is the official email by Linus:- https://lkml.org/lkml/2011/9/4/92

Let's see how things shape up in near future. But whoever is the hacker, he has done a smart job - getting root access is definitely not trivial, now we need to see what additional security measures will come in picture

Lot's to look forward to in coming days, let's follow the development closely.....

Linux - "Evaluate yourself"

In this article i would like to share some of  the tricky questions related to Linux, Let’s have a brain-storming session on Linux, for Linux enthusiasts am sure if you don’t know the answers, you would surely like to browse on these topics.

I will keep updating this article with more questions, here goes version 1 of my draft:- 

• Command to remove a file -file-name (name start with "-" )
• What is the -v flag for when using grep?
• What is the -h flag in rpm?
•  How would you direct stderr to stdout for a given command?
•  You type google.com into your preferred web browser - what happens? – how does DNS/squid/webserver comes into picture
•  Booting procedure of Linux?
•  What is initrd image?
•   How to restrict login to a server for maintenance
•   How to load a module in to the running kernel
•   How to unload a module from the running kernel.
•   How to boot in to single user mode.
•  What are the difference run levels in Linux

 Will add lot’s more in same article, consider this as first draft J 

Kernel Patch Management

Hello Readers,

Recently on open source mailing lists, there was a big discussion on patch related issues. I just thought of writing something on Linux “Patch management”

·         What is patch

·         How patch works

·         How to reverse the changes  

Patch: - The commands diff and patch form a powerful combination. They are widely used to get differences between original files and updated files in such a way that other people who only have the original files can turn them into the updated files with just a single patch file that contains only the differences. The patch program applies diff files to originals. The diff command is used to compare an original to a changed file. Diff lists the changes made to the file. A person who has the original file can then use the patch command with the diff file to add the changes to their original file (patching the file). Patch should be installed because it is a common way of upgrading applications.

If the patch file has extension gz or bz2, it need to be uncompressed before applying patch:-

·         gunzip patch-x.y.z.gz

·         bunzip2 patch-x.y.z.bz2

To apply a patch:-
patch -p1 </patch/to/file

Patches can be undone, or reversed, with the '-R' option:
patch -R </path/to/file

For complete details:-
man patch

Common errors and issues when applying patch:-

When a patch applies a patch file it verifies the sanity of the file in different ways

a.      Checking that the file looks like a valid patch file 

b.      Checking the code around the bits being modified matches the context 

provided in the patch 

If patch encounters something that doesn't look quite right it has two options:-

·         It can either refuse to apply the changes and abort

·         It can try to find a way to make the patch apply with a few minor changes.

Scenario 1:-

One example of something that's not 'quite right' that patch will attempt to fix 

if all the Context matches, the lines being changed match, but the 

line numbers are different. This can happen, for example if the patch 

makes a change in the middle of the file but for some reasons a few lines have 

been  added or  removed near the beginning of the file. In that case everything 

looks good it has just moved up or down  a bit, and patch will usually adjust the 

line  numbers  and apply the patch.

      Scenario 2:-

When patch encounters a change that it can't fix up with fuzz it rejects it outright 

and leaves  a file with a .rej extension (a reject file). You can 

read this file to  see exactly what change couldn't be 

applied, so you can  go fix it up manually.

      Scenario 3:- 

If patch stops and presents a "File to patch:" prompt, then patch could not find 

a  file to be  patched. Most likely you forgot to specify -p1 or you are in the wrong 

directory. Less often,  you'll find patches that need  to be applied with -p0 

instead  of -p1 (reading the patch file  should reveal if this is the case -- if 

so, then this is an error by the person who created the patch 

but it is not fatal).

     Scenario 4 :-

If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a message 

similar  to that,  then it means that patch had to adjust the location 

of the change  (in this example it needed to move 7 lines from 

where it  expected to make the change  to make it fit). The resulting file may or 

may not be OK, depending on the reason the file was different 

than expected. This often happens if you try to apply a patch  that 

was generated against a different  kernel version than the one you are trying 

to patch.

Scenario 5 :-

If you get a message like "Hunk #3 FAILED at 2387.", then it means that the patch 

could not  be applied correctly and the patch program was unable 

to fuzz its way through. This will generate  a .rej file with the      

change that caused the patch to fail and also a .orig file showing you the  original 

content that couldn't be  changed. 

Scenario 6 :-

 If you get "Reversed (or previously applied) patch detected!  Assume -R? [n]" then 

patch detected that the change contained in the patch seems to have already been 

made. If you actually did apply this patch previously and you just 

re-applied it in error, then just say [n]o and abort this patch. 

If you applied this  patch previously and actually intended to revert it, but forgot 

to specify -R, then you can say [y]es here to make patch revert it for 

you. This can also happen if the creator of the  patch reversed 

the source and  destination directories when creating the patch, and in that  case 

reverting the patch will in fact apply it.

       Patch Work project: - http://patchwork.ozlabs.org/
       

       Hope you like this article; Feel free to share your feedback. 

LInux Kernel Configuration and Compilation

Hello Readers,

New to Linux Kernel??

In this post, we will be learning about how to compile Linux kernel, how to get the source and make the kernel and to understand entire ecosystem of Linux kernel and to understand the configuration aspect.

KERNEL COMPILATION

The Linux kernel is the core of the operating system, acting as a layer between the hardware and all other processes. The kernel provides for memory management, multi-tasking, input/output, networking, and many other functions. Since Linux is open source software, access to the source code for the Linux kernel is freely available. This means that anyone is free to customize and recompile the kernel to suit their specific needs. In fact, the kernel is designed in a modular fashion that allows users to remove parts of the kernel that are not needed for the intended purpose of the machine

When thinking of customizing and recompiling the kernel, you may have visions of sorting through thousands of lines of C code, but that is not the case. Unneeded kernel modules can be removed without editing a single line of code. But, recompiling the kernel is not something that needs to be done frequently. It is a rather complex process. A combination of failing to make proper backups of the old kernel and errors in the compilation process can result in a system that does not function correctly or that does not boot up at all!

Kernel Version Numbers

The Linux kernel version numbers consist of three numbers separated by decimals, such as 2.6.14.

·         The first number is the major version number.

·         The second number is the minor revision number.

·         The third number is the patch level version.

At any given time there is a group of kernels that are considered “stable releases” and another group that is considered “development.”

If the second number of a kernel is even, then that kernel is a stable release. For example, the 2.6.14 kernel is a stable release because the second number is even. If the second number is odd, then that kernel is a development release. For example, the 2.5.51 is a development release because the second number is odd. Once the 2.5.x branch is considered finished, and then it will become the 2.6.0 kernel. Patches will then appear for the 2.6.x branch and development work will begin on the 2.7.x branch. If the 2.7.x advancements are significant enough to be considered a major revision, the 2.3.x branch will become 3.0.0 and development work will begin on the 3.1.x branch.

When should I upgrade to new kernel:-

New kernels are released rather frequently and the difference between two consecutive patch levels is usually minimal. Updating your kernel every time a new kernel is released is usually pointless unless the new version addresses an issue that directly affects you.

In the past, the kernel was not as modular as it is today. This means that older kernels used to load many unneeded modules into memory, thus increasing system load and also increasing the chances that bugs in those unneeded modules could adversely affect the system.

Recompiling the kernel to remove the unneeded modules had noticeable benefits. Newer kernels, however, usually load modules into memory only when they are needed. Manually removing these modules has little positive effect since they are not called by the kernel anyway.

Recompiling the kernel may be necessary if new hardware is added to the system that the current kernel does not support. For example, a system with a dual processor motherboard but only one processor installed most likely has a kernel that supports only one processor. If a second processor is installed at a later date, the kernel must be recompiled to support symmetric multi-processing (SMP) in order to utilize the second processor.

The process of compiling the kernel places a heavy load on the system, especially the RAM. On a busy server, there is being a noticeable degradation of system performance. Also, after the kernel has been compiled and installed, the system must be rebooted so that the new kernel can be used. Depending on the role of the machine, the downtime involved with rebooting the server can be costly. Consideration should be given to the items listed above before recompiling the kernel.

If you wish to upgrade to a newer kernel, you can patch your current kernel instead of downloading an entire new kernel. By patching your existing kernel, you retain your settings from previous kernel compilations. Patching the kernel is a good choice if you wish to upgrade from your current patch level to the next consecutive patch level. For example, patching kernel 2.2.5 to 2.2.6 involves applying one patch. However, if you wish to upgrade the 2.2.5 kernel to 2.2.14, then a patch for each patch level must be applied sequentially. In this case, it may be better to download the entire 2.2.14 kernel

Now we know the compilation process in theory, let’s compile the Linux kernel:-

Acquire Source

The best place to get the latest source at is http://kernel.org/. Choose the version you would like to use, either in the 2.6 or 2.4 branches and click on the F link on the right side. Save that file to the /usr/src directory on your machine. If you do not have a src directory, then simply create it.

Extract and Patch

Extract the source by running the following command:

---------------

[root@localhost root]# tar -xvjf linux-2.6.6.tar.bz2

---------------

If you downloaded any additional patch sets, then you will need to unzip them as follows:

---------------

[root@localhost root]# bunzip2 patch-2.6.6-bk5.bz2

---------------

After uncompressing the patches, then you can apply them to the source. Remember to apply them in order if you have more than one.

--------------------------------------------------------

[root@localhost root]# cd linux-2.6.6
[root@localhost root]# patch -p1 <../patch-2.6.6-bk5

--------------------------------------------------------

Assign a Unique Name

This is completely optional, but if you end up having to make several different revisions of the kernel, then you will find this quite helpful. Inside of the kernel directory is a file called Makefile. You should consider updating the EXTRAVERSION line to include a revision number, such as:

---

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 6
EXTRAVERSION = -1

---

Backup .config

If you have configured your kernel previously, then you should consider backing up your previous configuration as follows:

---

[root@localhost root]# cd linux
[root@localhost root]# cp .config config.save

---

Configure the Kernel :-  There are 4 main frontends to configuring the kernel: config, oldconfig, menuconfig, and xconfig. You simply choose one of these and type, for example, make menuconfig.

a. config is the least user-friendly option as it merely presents a series of questions that must be answered sequentially. Alas, if an error is made you must begin the process from the top. Pressing Enter will accept the default entry, which is in upper case.

b. oldconfig will read the defaults from an existing .config and rewrite necessary links and files. Use this option if you've made minor changes to source files or need to script the rebuild process. Note that oldconfig will only work within the same major version of the kernel. You cannot, for example, use a 2.4.x .config with the 2.6.x kernel.

c. menuconfig is probably the best option if you do not have X-Windows available.

d.   xconfig, as the name suggests, is an X-Windows based frontend. It uses the Tcl/TK libraries to present a nice GUI that is similar in structure to the ncurses config used with the menuconfig. Below is an example screen:

Once you have made all of your configurations, you can save your settings. By default, it will save as .config in the topmost directory. You can save this here, but I advise you to copy this file after you exit this utility.

Build Dependencies

The next step is create all of the necessary include files that the kernel needs to run and compile. If you are compiling a 2.4.x kernel, then run the following:

---

[root@localhost root]# make dep

[root@localhost root]# make clean

---

With the 2.6.x kernels, these 2 steps can be skipped.

Build the Kernel

We are now (finally) ready to start the actual kernel build. At the prompt type:

---

[root@localhost root]# make bzImage

---

Build the Modules

Although you have finished building the kernel, without all of the modules that the kernel loads and runs, the system will be pretty useless. You need to run the following 2 commands to build and install the modules:

----

[root@localhost root]# make modules

[root@localhost root]# make modules_install

----

Install

Not sure if this works or not on the 2.4.x kernels, but running the following command on a 2.6.x kernel will make the appropriate boot images and update grub as needed to include this kernel.

---

[root@localhost root]# make install

---

Reboot and Test

Simply reboot the system and then from the grub menu, choose the kernel that you built. If all goes well, then you should be up and running with all of your peripherals responding correctly and without any crashes. If, however, something breaks, you still have your prior kernels you can go back to at any time.

Hope you liked the article; feel free to post your comments/suggestions if any.

Articles related to system and kernel boot process

Hello Readers,

In this post i would like to share link to some of the best articles i have read in recent time:-

a. Article related to "Motherboard chipset and Memory map"
http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map

b. How PC Boots up
http://duartes.org/gustavo/blog/post/how-computers-boot-up

c. The Kernel boot process
http://duartes.org/gustavo/blog/post/kernel-boot-process

I am quite positive you guys will love these write-up's. I will be sharing more of such links in future posts. Let's share more and learn more.

GITWEB

Once we have the GIT server up and running with the repository structures in place, we need to explore more about GITWEB, so as to make browsing of repositories easier. This post will provide pointers related to setting up GITWEB and its configuration.

 

What is GITWEB??

• 'Gitweb' is a Git web interface, the one working on http://www.kernel.org/git
• It is written in Perl, and can be used as a CGI script, or as a mod_perl legacy script
• It allows browsing a git repository (or a set of git repositories) using a web browser.
• Using gitweb we can browse directory trees at arbitrary revisions, view contents of files, see log or examine commits, commit messages and changes made by a given commit.
• We can search for commits by an author, added to repository by a comitter, commit with commit message (commit description) which includes some text.

GITWEB CONFIGURATION

Install Apache

First, you need to ensure apache2 is installed. Check to see if you have an /etc/apache2 folder. If you do, you should be okay. If you don’t, you need to install it.  sudo apt-get install apache2

Once you have that installed and the daemon is restarted, type the ip address in the browser and you should something like “It Works” 

Issues related to Apache

There can be lot of issues related to apache configuration, some are listed below:-

There may be a firewall running on your server, and it might be blocking traffic to the standard web server ports, port 80 (for regular connections) and port 443 (for secure connections).

Check the current firewall rule:-

sudo  /sbin/iptables –L

IP table rules to open the ports

sudo /sbin/iptables -I INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo /sbin/iptables -I OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
sudo /sbin/iptables -I INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo /sbin/iptables -I OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

Logs

Apache logs are stored under:- /var/log/apache2     

Test the server

If you navigate to your server's IP address in a web browser: http://<ip address>

You should see a default page telling you apache is working

INSTALL GITWEB

sudo apt-get install gitweb

This will install gitweb into /var/www/gitweb, create a conf file at /etc/gitweb.conf, and add three files to /usr/share/gitweb (git-favicon.png, git-logo.png, gitweb.css).

If for some reason, the /var/www/gitweb folder is not created, you can clone the git source (git clone git://git.kernel.org/pub/scm/git/git.git) and then just copy the git/gitweb folder to /var/www/gitweb

cp –R git/gitweb /var/www/

You only need to edit the $projectroot variable in the /etc/gitweb.conf to point to your repositories folder:

/etc/gitweb.conf

=============================== 

# path to git projects (<project>.git)
$projectroot = "/project";
# directory to use for temp files
$git_temp = "/tmp";
# target of the home link on top of all pages
#$home_link = $my_uri || "/";
# html text to include at home page
$home_text = "indextext.html";
# file with project list; by default, simply scan the projectroot dir.
$projects_list = $projectroot;
# stylesheet to use
$stylesheet = "/gitweb/gitweb.css";
# logo to use
$logo = "/gitweb/git-logo.png";
# the 'favicon'
$favicon = "/gitweb/git-favicon.png";
#enable human readable URLs
$feature{'pathinfo'}{'default'} = [1];

===============================

Since Ubuntu includes the entire /etc/apache2/conf.d directory, so we just added the following information into /etc/apach2/conf.d/gitweb:-

 /etc/apache2/conf.d/gitweb.conf

===============================
AddHandler cgi-script .cgi
#</Directory>
ServerName hostname1
<Directory /var/www/gitweb>
RewriteRule ^/gitweb/([a-zA-Z0-9_\-]+\.git)/?(\?.*)?$ /cgi-bin/gitweb.cgi/$1 [L,PT]
Options Indexes FollowSymlinks ExecCGI
DirectoryIndex /cgi-bin/gitweb.cgi
AllowOverride None
</Directory>

 /etc/apache2/sites-enabled/000-defaul

===============================
 Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

ScriptAlias /git "/usr/lib/cgi-bin/gitweb.cgi"
        <Directory "/var/www/gitweb">
                Options Indexes FollowSymLinks ExecCGI
                Order allow,deny
                Allow from all
        </Directory>
</VirtualHost>
===============================

Restart Apache to make sure everything works....

Congratulation, the gitweb is up and running on your system now. Hope you find this article useful, If there are any issues or concerns feel free to share your feedback.

Open source version control management

GIT is a distributed revision control system with an emphasis on speed.
GIT was initially designed and developed by Linus Torvalds for Linux kernel development.
Later on, GIT became the de facto standard in the open source community.

The main design goals behind GIT are:-

·         Support for distributed workflow

·         Very high performance

·         Very strong safeguards against corruption

GIT is free software. It is distributed under the terms of GNU General Public License v2. The GIT provides only the basic functionality for SCM operations. It can be seen as a versioning file-system. GIT does not have any notion of users or access rights. Nor it has any graphical user interface. All these are built on top of GIT by additional tools, like Gerrit.

Let's get started:-
Initializing the build environment

64-bit systems:

---------------------------------
$ sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev libgl1-mesa-dev
---------------------------------

More information on initializing the build environment can be found at:-
http://source.android.com/source/initializing.html

Download the GIT Source
Use your favorite package installer to install git-core and gitosis packages:
sudo apt-get -y install git-core

Installing Repo
Repo is a tool that makes it easier to work with Git in the context of Android. For more information about Repo
To install, initialize, and configure Repo, follow these steps

Make sure you have a bin/ directory in your home directory, and that it is included in your path:

-----
$ mkdir ~/bin
$ PATH=~/bin:$PATH
$ curl http://android.git.kernel.org/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
-----

After installing Repo, set up your client to access the android source repository:-

Create an empty directory to hold your working files:

Run repo init to bring down the latest version of Repo with all its most recent bug fixes. We must specify a URL for the manifest, which specifies where the various repositories included in the Android source, will be placed within your working directory.

$ repo init -u git://hostname/local/platform/manifest.git

To check out a branch other than "master", specify it with -b:

When prompted, configure Repo with your real name and email address. To use the Gerrit code-review tool, you will need an email address. Make sure this is a live address at which you can receive messages.

A successful initialization will end with a message stating that Repo is initialized in your working directory. Your client directory should now contain a .repo directory where files such as the manifest will be kept.

To pull down files to your working directory from the repositories as specified in the default manifest, run $repo sync

Let’s learn something about manifest file, how it works and what it contains?

What is a Manifest file??
It’s a xml file, which contains information related to:-
·         Remote
·         Revisions
·         Project path
·         Project name


Manifest file is a xml file which contains all the information about:-
Projects:-
Which are the git projects that have to be synced, where those projects are located, which revision of those git projects should be picked while syncing to local directory.

Remote:-
Points to the generic path of the git repositories.

Revision: -
Specifies which branch or tag or commit needs to be picked up while syncing.

Useful Links to explore mode on GIT:-
http://www.gitref.org
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
 http://progit.org/book/
 http://git-scm.com/
http://www.github.com