.so: cannot open shared object file: Permission denied

When I start the application in debug mode (sh -x) it works fine after taking few seconds while loading the libraries but without debug mode it failes with .so : cannot open shared object file: Permission denied even though it has proper read permission as well as proper read permission to all parent folders.

Then I figured out that its due to selinux in enforcing state.

Change : /etc/selinux/config from SELINUX=enforcing ## or permissive to SELINUX=disabled

What is the difference between NIC Teaming and Bonding

NIC Teaming and NIC bonding are two different things.

NIC Teaming uses one of two methods, failover, and load-balancing with fail over. With a team you do not get a single 2gb connection (with two 1 gb NICs). You get two pipes that act as one, but merely are load balancing the traffic over each NIC, and each NIC acts as a fail over to the other. If you transfer a 100 gb file, you are not going to get 2gb of throughput…you still only get 1 gb, but you will not kill the network performance because the second NIC is still available to service other traffic.

True bonding would be taking two NICs and bonding them together to get a single fat pipe. This requires the switch to support this as well. I have not seen much bonding in the server world…more done at the network level.

VMWare acts the same way. It is purely load balancing and fail over. Since VMWare is done at the OS level, you can mix and match different vendor NICs in a team. I have done this without issue. Just make sure they are on the HCL.

Difference between GIT and SVN

If you are reading this article, you obviously care about GIT like lot of developers do and if you haven’t had a chance to get some taste of GIT, I think it’s time to wake up.

GIT is much more than a version control system, it can be used as CMS, workspace manager etc. It will take a mind shift for anyone coming from SVN background to get used to some of the concepts & features that GIT offers. So, the main purpose of this article is to help them by giving ideas on what to expect from GIT and how it’s different from SVN from high-level.

Alright, here it goes…

  1. GIT is distributed, SVN is not: 

    This is by far the *core* difference between GIT and other non-distributed version control systems like SVN, CVS etc. If you can catch this concept well, then you have crossed half the bridge. To add a disclaimer, GIT is not the first or only distributed VCS(version control system) currently available. There are other tools like BitkeeperMercurial etc. which also work on distributed mode. But, GIT does it better and comes with much more powerful features.

    GIT like SVN do have centralized repository or server. But, GIT is more intended to be used in distributed mode which means, every developers checking out code from central repository/server will have their own cloned repository installed on their machine. Let’s say if you are stuck somewhere where you don’t have network connectivity, like inside the flight, basement, elevator etc. :) , you will still be able to commit files, look at revision history, create branches etc. This may sound trivial for lot of people but, it is a big deal when you often bump into no-network scenario.
    And also, the distributed mode of operation is a biggest blessing for open-source software development community. Instead of creating patches & sending it thro emails, you can create a branch & send a pull request to the project team. It will help the code stay streamlined without getting lost in transport. GitHub.com is an awesome working example of that.

    There were some rumors that the future version of subversion will be working on distributed mode. But, it’s still an unknown at this point.

  2. GIT stores content as metadata, SVN stores just files: 

    Every source control systems stores the metadata of files in hidden folders like .svn, .cvs etc., whereas GIT stores entire content inside the .git folder. If you compare the size of .git folder with .svn, you will notice a big difference. So, the .git folder is the cloned repository in your machine, it has everything that the central repository has like tags, branches, version histories etc.

  3. GIT branches are not the same as SVN branches: 

    Branches in SVN are nothing but just another folder in the repository. If you need to know if you had merged a branch, you need to explicitly run commands like svn propget svn:mergeinfo to verify if it was merged or not. Thanks Ben for pointing this feature :) .
    So, the chance of adding up orphan branches is pretty big.

    Whereas, working with GIT branches is much more easier & fun. You can quickly switch between branches from the same working directory. It helps finding un-merged branches and also help merging files fairly easily & quickly.

  4. GIT does not have a global revision no. like SVN do: 

    This is one of the biggest feature I miss in GIT from SVN so far. As you may know already SVN’s revision no. is a snapshot of source code at any given time. I consider that as a biggest breakthrough moving from CVS to SVN.
    Since, GIT & SVN are conceptually different, I don’t know how you can mirror that feature in GIT. If anyone know of any tricks that can do this, please feel free to share it in the comments.
    Update: As some of the readers pointed out, you can use GIT’s SHA-1 hash key to uniquely identify the code snapshot. It may not exactly replace SVN’s easily readable numeric revision no. but, it kind of serves the same purpose.

  5. GIT’s content integrity is better than SVN’s: 

    GIT contents are cryptographically hashed using SHA-1 hash algorithm. This will ensure the robustness of code contents by making it less prone to repository corruption due to disk failures, network issues etc. Here is an interesting discussion on GIT’s content integrity – http://stackoverflow.com/questions/964331/git-file-integrity

Are those only 5 differences between GIT & SVN? Well, not really :) . I thought 5 rhymes with “fundamental” &“fascinating”, I came up with that number. If you can think of a better one than the one’s listed here, feel free to share them, I might be willing to trade them with these ones.

Brief about the initial process sequence while the system boots up.

While booting, special process called the ‘swapper’ or ‘scheduler’ is created with Process-ID 0. The swapper manages memory allocation for processes and influences CPU allocation. The swapper inturn creates 3 children:

  • the process dispatcher,
  • vhand and
  • dbflush

with IDs 1,2 and 3 respectively.
This is done by executing the file /etc/init. Process dispatcher gives birth to the shell. Unix keeps track of all the processes in an internal data structure called the Process Table (listing command is ps -el).

How does the inode map to data block of a file?

Inode has 13 block addresses. The first 10 are direct block addresses of the first 10 data blocks in the file. The 11th address points to a one-level index block. The 12th address points to a two-level (double in-direction) index block. The 13th address points to a three-level(triple in-direction)index block. This provides a very large maximum file size with efficient access to large files, but also small files are accessed directly in one disk read.