Friday, February 28, 2014
Tuesday, February 7, 2012
Wednesday, December 28, 2011
Android Link's
Android Booting
http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html
http://www.androidenea.com/2009/08/init-process-and-initrc.html
http://www.vogella.de/articles/AndroidInternals/article.html
http://blog.csdn.net/loughsky/article/details/3293922
-----------------------------------------------------------------------------------------------------------------
http://honeypod.blogspot.com/2007/12/initialize-libc-for-android.html
http://discuz-android.blogspot.com/search/label/Bionic%20libc
http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html
http://www.androidenea.com/2009/08/init-process-and-initrc.html
http://www.vogella.de/articles/AndroidInternals/article.html
http://blog.csdn.net/loughsky/article/details/3293922
-----------------------------------------------------------------------------------------------------------------
http://honeypod.blogspot.com/2007/12/initialize-libc-for-android.html
http://discuz-android.blogspot.com/search/label/Bionic%20libc
Friday, December 16, 2011
Evolution of shells in Linux
Pointing and clicking is fine for most day-to-day computing tasks, but
to really take advantage of the strengths of Linux over other environments, you eventually
need to crack the shell and enter the command line. Lots of command shells are available, from
Bash and Korn to C shell and various exotic and strange shells. Learn which shell is
right for you.
read more...
read more...
Wednesday, December 14, 2011
Manage System Startup and Boot Processes on Linux with Upstart
Want to start, stop, and manage services on your Linux box? Then you
need to familiarize yourself with Upstart and take control of your
startup and boot processes on Linux.
When Linux boots up, the first process that runs is called
BSD, System V, Upstart and systemd
You might think that the way that the system starts would be fairly
well-agreed upon between Linux distributions. Unfortunately, that's not
been the case and may not be the case for some time.
Linux isn't directly derived from UNIX, but it takes a lot of ideas from UNIX, including the way that the system starts. Some Linux distros, most notably Slackware, used the BSD-style init. Slackware (and its derivatives) is the lone holdout for this style these days, and it includes a System V init compatibility workaround so that applications that expect to support System V init scripts can install them normally.
System V (from UNIX System V), the precursor to was the standard for most Linux distros for many years. Distros using SysV init would have several directories under
What's a runlevel, you ask? Essentially this is the grouping of services that are run by init. For example, runlevel 0 is "halt," runlevel 1 or S are the "single user mode," and runlevel 6 is reboot. On Fedora/Red Hat systems, runlevel 3 is a full set of services to run a multiuser system (networking, etc.), and runlevel 5 includes multiuser services and X11 with the display manager. You'll notice I didn't mention 2 or 4, because those runlevels are rarely used and runlevel 4 isn't even defined by default.
Note that you can switch between runlevels using the
Under each of the directories, you'd have a set of symbolic links that point back to scripts that include startup and shutdown directives for services like Apache and the SSH daemon. Each link has a name like
So now we have, or had, Upstart as the emerging standard. For now, Upstart is the sort-of standard for several distros. Upstart is used by Ubuntu, current Fedora releases, and openSUSE 11.3 includes it as an optional package. But the Fedora folks are working on a replacement for Upstart called systemd, which is a "system and session manager" that is meant to be a "drop-in replacement for sysvinit." There's a very detailed discussion of the rationale behind systemd by Lennart Poettering that is an interesting read if you're interested in the deep details. So at some point, you'll need to know Upstart or systemd, or both if you are managing systems using Upstart and systemd.
For now, we're going to look at Upstart.
For applications managed with Upstart, you'll first want to look at the
To see what's running on your system, use
To stop a job that's running, use
For jobs that are managed by Upstart, you can edit their configuration file under
If you're using a desktop system, you'll want to install the Boot-up Manager — a GUI tool for handling runlevel configuration. The package is
Note that Fedora uses Upstart in SysV compatibility mode, which means that a lot of jobs on Fedora are not managed with native Upstart scripts. For those jobs you'll want to use the
To see the status of all jobs on Fedora using
This will show which jobs are stopped, running, and in a few instances much more information. For example, iptables will spit out its entire set of policies that are running at the moment.
To manage a job with
If you want to tweak the services by runlevel, use the
What if you want to add a service or modify the scripts for existing services? One quick and dirty way is to use
Typically, this is unnecessary — almost any service that you'll be using should have init scripts pre-written. Writing an init script, whether for Upstart or for SysV, is a bit outside the scope of this tutorial.
Since many users are going to be transitioning to systemd, we'll take a longer look at managing jobs with systemd when Fedora 15 comes out.
Most of the time, your interaction with managing services should be minimal unless you're working with Linux as a full-time admin. If you are doing system administration, or planning to, you should already be familiar with the init system that your distros are using. If not, now's a good time to learn. If you're a desktop Linux user, you probably won't be managing services very often, but it's a good to know the basics that we've covered here in case you need to do any troubleshooting or just want to fine-tune your system.
Ref: https://www.linux.com/learn/tutorials/404619-manage-system-startup-and-boot-processes-on-linux-with-upstart
https://www.linux.com/learn/tutorials/524577
When Linux boots up, the first process that runs is called
init. From there, init takes the task of starting up system processes. But which init? Turns out, there are several flavors of init,
and it depends on which Linux distribution you're using and how modern
the release is. Let's take a look at some of the backstory.
BSD, System V, Upstart and systemd init, Oh My...
You might think that the way that the system starts would be fairly
well-agreed upon between Linux distributions. Unfortunately, that's not
been the case and may not be the case for some time.Linux isn't directly derived from UNIX, but it takes a lot of ideas from UNIX, including the way that the system starts. Some Linux distros, most notably Slackware, used the BSD-style init. Slackware (and its derivatives) is the lone holdout for this style these days, and it includes a System V init compatibility workaround so that applications that expect to support System V init scripts can install them normally.
System V (from UNIX System V), the precursor to was the standard for most Linux distros for many years. Distros using SysV init would have several directories under
/etc such as rc0.d, rc1.d, through rc6.d for each runlevel — though many of the runlevels are not really implemented.What's a runlevel, you ask? Essentially this is the grouping of services that are run by init. For example, runlevel 0 is "halt," runlevel 1 or S are the "single user mode," and runlevel 6 is reboot. On Fedora/Red Hat systems, runlevel 3 is a full set of services to run a multiuser system (networking, etc.), and runlevel 5 includes multiuser services and X11 with the display manager. You'll notice I didn't mention 2 or 4, because those runlevels are rarely used and runlevel 4 isn't even defined by default.
Note that you can switch between runlevels using the
telinit command, like so: telinit 3 would switch to runlevel 3, and telinit 6 would tell the system to reboot. Note that you would usually want to just use reboot instead to reboot, but telinit 6 would also work.Under each of the directories, you'd have a set of symbolic links that point back to scripts that include startup and shutdown directives for services like Apache and the SSH daemon. Each link has a name like
KNNsshd or SNNcups, where the NN
determines the order in which services are killed (K) or started (S).
This became tricky with laptops and mobile systems, because the state of
a computer might determine the order in which services should be
started. See the rationale
for Upstart by Scott James Remnant for more detail — but the short of
it is that the SysV style init that served Linux well for many years
became rather fragile and creaky when Linux adapted to use as a notebook
OS as much as a server OS.So now we have, or had, Upstart as the emerging standard. For now, Upstart is the sort-of standard for several distros. Upstart is used by Ubuntu, current Fedora releases, and openSUSE 11.3 includes it as an optional package. But the Fedora folks are working on a replacement for Upstart called systemd, which is a "system and session manager" that is meant to be a "drop-in replacement for sysvinit." There's a very detailed discussion of the rationale behind systemd by Lennart Poettering that is an interesting read if you're interested in the deep details. So at some point, you'll need to know Upstart or systemd, or both if you are managing systems using Upstart and systemd.
For now, we're going to look at Upstart.
Managing Startup Services
Now, when we're talking about startup services, I mean the system-wide services like SSH and Apache, not the applications started up by your desktop. That's a whole different kettle of fish, and depends on the desktop that you're using. For example, if you're running a recent Linux distro with GNOME, you'll look at System -> Preferences -> Startup Applications.For applications managed with Upstart, you'll first want to look at the
initctl command. This allows you to work with Upstart's init daemon. Naturally, you're going to need to use sudo to run initctl or be logged in as root.To see what's running on your system, use
initctl list. You'll see something like this:alsa-mixer-save stop/waiting
avahi-daemon start/running, process 690
mountall-net stop/waiting
rc stop/waiting
rsyslog start/running, process 482
screen-cleanup stop/waiting
tty4 start/running, process 859
udev start/running, process 334
upstart-udev-bridge start/running, process 304
ureadahead-other stop/waiting rsyslog. The second field is the "goal" of the job, followed by the state of the job.To stop a job that's running, use
initctl stop job. To start a job, run initctl start job. You can also request status of jobs with initctl status job. Finally you can restart or reload jobs with the restart and reload
commands. What's the difference between restarting and reloading?
Restarting does what it says on the tin — stops the job and then
restarts it. The reload command sends the SIGHUP signal to the job, which can be used to tell a daemon to re-read its configuration.For jobs that are managed by Upstart, you can edit their configuration file under
/etc/init. They will have a few lines that describe which runlevels to start/stop on like so:start on runlevel [2345]
stop on runlevel [!2345] If you're using a desktop system, you'll want to install the Boot-up Manager — a GUI tool for handling runlevel configuration. The package is
bum, and it will let you manage jobs and configure
services by runlevel. It's simple to use, and shouldn't require a lot of
guidance.Note that Fedora uses Upstart in SysV compatibility mode, which means that a lot of jobs on Fedora are not managed with native Upstart scripts. For those jobs you'll want to use the
service command.To see the status of all jobs on Fedora using
service run:service --status-allThis will show which jobs are stopped, running, and in a few instances much more information. For example, iptables will spit out its entire set of policies that are running at the moment.
To manage a job with
service use service servicename command. The servicename is the name of the configuration script under /etc/init.d. For example, to start and stop the openSSH daemon, you'll use service sshd start or service sshd stop.If you want to tweak the services by runlevel, use the
chkconfig command. You'd use something like chkconfig --level 35 cups on to tell chkconfig to make sure that cups is started in runlevels 3 and 5.What if you want to add a service or modify the scripts for existing services? One quick and dirty way is to use
/etc/rc.local. The script should be run during any startup or change of runlevel. Another way is to modify the scripts under /etc/init.d (for SysV compatibility) or /etc/init (native Upstart scripts) or write your own for a new service.Typically, this is unnecessary — almost any service that you'll be using should have init scripts pre-written. Writing an init script, whether for Upstart or for SysV, is a bit outside the scope of this tutorial.
Since many users are going to be transitioning to systemd, we'll take a longer look at managing jobs with systemd when Fedora 15 comes out.
Most of the time, your interaction with managing services should be minimal unless you're working with Linux as a full-time admin. If you are doing system administration, or planning to, you should already be familiar with the init system that your distros are using. If not, now's a good time to learn. If you're a desktop Linux user, you probably won't be managing services very often, but it's a good to know the basics that we've covered here in case you need to do any troubleshooting or just want to fine-tune your system.
Ref: https://www.linux.com/learn/tutorials/404619-manage-system-startup-and-boot-processes-on-linux-with-upstart
https://www.linux.com/learn/tutorials/524577
Monday, October 31, 2011
Vim Tips
1.I always wished that as a programmer , I should not waste my time in
writing the trivial stuff, the one I require every time I sit to write the
program. For example, while writing any C-program, we have the general
format of #include<...> & then main() { ... return 0 ; }
What if every time I start writing the program, this format is ready for me
?? Well thats possible, atleast with "vim".
Create the standard format of the file you want , lets say at <~/format> is
the path.
Now start vim : vim ,& then type , in command-mode ---> :r
~/format ,thats all , whatever is in the file <~/format> will be simply
pasted .
I have created the file : <~/lic.c> , it contains the GNU GPL disclaimer.
Now after I finish writing the program , I just have to say ( in command
mode ) --> :r ~/lic.c , thats all, the license-terms get pasted .
It looks like this :
/* ########################################################################
*
*LAST UPDATED :
*Copyright (C) 2011 Lokesh Walase
*
* Released under GNU General Public License v2.0+ .
* FOR DETAILED LICENSE, SEE THE END OF THIS PROGRAM.
*
*########################################################################
*/
/*####################################################################################################################
*
*This program is free software; you can redistribute it and/or modify
*it under the terms of the GNU General Public License as published by
*the Free Software Foundation; either version 2 of the License, or
*(at your option) any later version.
*
*This program is distributed in the hope that it will be useful,
*but WITHOUT ANY WARRANTY; without even the implied warranty of
*MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
*GNU General Public License for more details.
*
* Visit
*
*To receive a copy of the GNU General Public License
* write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
*Boston, MA 02110-1301 USA
*The GNU General Public License does not permit incorporating this program
*into proprietary programs.
*
*
########################################################################################################################
*/
2.As you might have noticed , the <~/lic.c> has the field --> LAST UPDATED
: , now to put the date & time here , go to that line, & in command mode
---> :r !date .
3.Well, if that didnt really raise your eyebrows, here's somemore . What is
the best thing of the "terminal" ?? Yes, it "auto-completes" the commands
by '\t' key. Now what if the same feature of "auto-completion" is present
everywhere & not only in the "terminal" ?? Well thats possible, (again)
atleast with "vim" .
Create a new <.vimrc> file in your home-folder . Say : vim .vimrc , at your
home-folder & then copy paste this code( I found it on net ) :
*function! Tab_Or_Complete()
if col('.')>1 && strpart( getline('.'), col('.')-2, 3 ) =~ '^\w'
return "\"
else
return "\"
endif
endfunction
:inoremap =Tab_Or_Complete()
:set dictionary="/usr/dict/words"
*
Pls be sure of the indentation ,everything has to be strictly indented . I
dont know what exactly it is doing .
Now vim will "auto-complete" any words you type , press '\t' for the same .
Its indeed cool ........proud to be a "vimmer" !! ;)
4.Now whats next ?? Well, enough of vim. Recently I came to know of the
command that can convert .pdf files to text-files, post-script files ,
html-files & many more. Just type in the terminal & then you press
'\t' twice to see all the options .
Reading man pages is boring , so u may convert a lengthy man-page to a html
file & get a nice look & feel to read it , I did it for "info flex" .
Type : info flex > flex.odt . Now open flex.odt & get its pdf format , &
then use command --> pdftohtml flex.pdf flex.html
Ref : http://groups.google.com/group/cofsug/browse_thread/thread/d5edacf343486d03?hl=en-GB
writing the trivial stuff, the one I require every time I sit to write the
program. For example, while writing any C-program, we have the general
format of #include<...> & then main() { ... return 0 ; }
What if every time I start writing the program, this format is ready for me
?? Well thats possible, atleast with "vim".
Create the standard format of the file you want , lets say at <~/format> is
the path.
Now start vim : vim
~/format ,thats all , whatever is in the file <~/format> will be simply
pasted .
I have created the file : <~/lic.c> , it contains the GNU GPL disclaimer.
Now after I finish writing the program , I just have to say ( in command
mode ) --> :r ~/lic.c , thats all, the license-terms get pasted .
It looks like this :
/* ########################################################################
*
*LAST UPDATED :
*Copyright (C) 2011 Lokesh Walase
*
* Released under GNU General Public License v2.0+ .
* FOR DETAILED LICENSE, SEE THE END OF THIS PROGRAM.
*
*########################################################################
*/
/*####################################################################################################################
*
*This program is free software; you can redistribute it and/or modify
*it under the terms of the GNU General Public License as published by
*the Free Software Foundation; either version 2 of the License, or
*(at your option) any later version.
*
*This program is distributed in the hope that it will be useful,
*but WITHOUT ANY WARRANTY; without even the implied warranty of
*MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
*GNU General Public License for more details.
*
* Visit
*
*To receive a copy of the GNU General Public License
* write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
*Boston, MA 02110-1301 USA
*The GNU General Public License does not permit incorporating this program
*into proprietary programs.
*
*
########################################################################################################################
*/
2.As you might have noticed , the <~/lic.c> has the field --> LAST UPDATED
: , now to put the date & time here , go to that line, & in command mode
---> :r !date .
3.Well, if that didnt really raise your eyebrows, here's somemore . What is
the best thing of the "terminal" ?? Yes, it "auto-completes" the commands
by '\t' key. Now what if the same feature of "auto-completion" is present
everywhere & not only in the "terminal" ?? Well thats possible, (again)
atleast with "vim" .
Create a new <.vimrc> file in your home-folder . Say : vim .vimrc , at your
home-folder & then copy paste this code( I found it on net ) :
*function! Tab_Or_Complete()
if col('.')>1 && strpart( getline('.'), col('.')-2, 3 ) =~ '^\w'
return "\
else
return "\
endif
endfunction
:inoremap
:set dictionary="/usr/dict/words"
*
Pls be sure of the indentation ,everything has to be strictly indented . I
dont know what exactly it is doing .
Now vim will "auto-complete" any words you type , press '\t' for the same .
Its indeed cool ........proud to be a "vimmer" !! ;)
4.Now whats next ?? Well, enough of vim. Recently I came to know of the
command that can convert .pdf files to text-files, post-script files ,
html-files & many more. Just type
'\t' twice to see all the options .
Reading man pages is boring , so u may convert a lengthy man-page to a html
file & get a nice look & feel to read it , I did it for "info flex" .
Type : info flex > flex.odt . Now open flex.odt & get its pdf format , &
then use command --> pdftohtml flex.pdf flex.html
Ref : http://groups.google.com/group/cofsug/browse_thread/thread/d5edacf343486d03?hl=en-GB
Wednesday, October 19, 2011
How do I make changes to a package and capture them using ltib
1. Unpack the sources and apply all current patches:
3. Build the package with your changes:
./ltib -m prep -p u-boot
2. Edit/add files under rpm/BUILD/package/
3. Build the package with your changes:
./ltib -m scbuild -p u-boot
4. Once the package builds successfully, check the install phase:
./ltib -m scinstall -p u-boot
5. Test your package before committing the changes:
./ltib -m scdeploy -p u-boot
6. Repeat steps 2 -> 5 until you are satisfied with your results.
Ref: http://ltib.org/documentation-LtibFaq
Subscribe to:
Posts (Atom)