mirror of https://github.com/tLDP/LDP
parent
c72249d0d6
commit
14df4d2974
|
@ -29,124 +29,97 @@ CLI
|
|||
application in which the user responds to a visual prompt by typing in a command on a
|
||||
specified line, receives a response back from the system, and then enters another command,
|
||||
and so forth. The MS-DOS Prompt application in a Windows operating system is an example of
|
||||
the provision of a command line interface. Today, most users prefer the graphical user interface
|
||||
(GUI) offered by Windows, Mac OS, BeOS, and others. Typically, most of today's Unix-based systems
|
||||
offer both a command line interface and a graphical user interface.
|
||||
|
||||
core
|
||||
A core file is created when a program terminates unexpectedly, due to a bug, or a violation of
|
||||
the operating system's or hardware's protection mechanisms. The operating system kills the
|
||||
program and creates a core file that programmers can use to figure out what went wrong. It
|
||||
contains a detailed description of the state that the program was in when it died. If would
|
||||
like to determine what program a core file came from, use the file command, like this: $ file core
|
||||
That will tell you the name of the program that produced the core dump. You may want to write
|
||||
the maintainer(s) of the program, telling them that their program dumped core. To Enable or
|
||||
Disable Core Dumps you must use the ulimit command in bash, the limit command in tcsh, or the
|
||||
rlimit command in ksh. See the appropriate manual page for details. This setting affects all
|
||||
programs run from the shell (directly or indirectly), not the whole system. If you wish to enable
|
||||
or disable core dumping for all processes by default, you can change the default setting in
|
||||
/usr/include/linux/sched.h. Refer to definition of INIT_TASK, and look also in
|
||||
/usr/include/linux/resource.h. PAM support optimizes the system's environment, including the amount
|
||||
of memory a user is allowed. In some distributions this parameter is configurable in the
|
||||
/etc/security/limits.conf file. For more information, refer to the Linux Administrator's Security Guide.
|
||||
|
||||
the provision of a command line interface. Today, most users prefer the graphical user
|
||||
interface (GUI) offered by Windows, Mac OS, BeOS, and others. Typically, most of today's
|
||||
Unix-based systems offer both a command line interface and a graphical user interface.
|
||||
|
||||
daemon
|
||||
A process lurking in the background, usually unnoticed, until something triggers it into action.
|
||||
For example, the \cmd{update} daemon wakes up every thirty seconds or so to flush the buffer cache,
|
||||
and the \cmd{sendmail} daemon awakes whenever someone sends mail.
|
||||
A process lurking in the background, usually unnoticed, until something triggers it into
|
||||
action. For example, the \cmd{update} daemon wakes up every thirty seconds or so to
|
||||
flush the buffer cache, and the \cmd{sendmail} daemon awakes whenever someone sends mail.
|
||||
|
||||
DARPA
|
||||
The Defense Advanced Research Projects Agency is the central research and development organization
|
||||
for the Department of Defense (DoD). It manages and directs selected basic and applied research
|
||||
and development projects for DoD, and pursues research and technology where risk and payoff are
|
||||
both very high and where success may provide dramatic advances for traditional military roles and
|
||||
missions.
|
||||
The Defense Advanced Research Projects Agency is the central research and development
|
||||
organization for the Department of Defense (DoD). It manages and directs selected basic
|
||||
and applied research and development projects for DoD, and pursues research and
|
||||
technology where risk and payoff are both very high and where success may provide
|
||||
dramatic advances for traditional military roles and missions.
|
||||
|
||||
DHCP
|
||||
Dynamic Host Control Protocol, is a protocol like BOOTP (actually dhcpd includes much of the
|
||||
functionality of BOOTPD). It assigns IP addresses to clients based on lease times. DHCP is used
|
||||
extensively by Microsoft and more recently also by Apple. It is probably essential in any
|
||||
multi-platform environment.
|
||||
Dynamic Host Control Protocol, is a protocol like BOOTP (actually dhcpd includes much
|
||||
of the functionality of BOOTPD). It assigns IP addresses to clients based on lease times.
|
||||
DHCP is used extensively by Microsoft and more recently also by Apple. It is probably
|
||||
essential in any multi-platform environment.
|
||||
|
||||
DNS
|
||||
Domain Name System translates Internet domain and host names to IP addresses. DNS implements a
|
||||
distributed database to store name and address information for all public hosts on the Net.
|
||||
DNS assumes IP addresses do not change (i.e., are statically assigned rather than dynamically
|
||||
assigned). The DNS database resides on a hierarchy of special-purpose servers. When visiting a
|
||||
Web site or other device on the Net, a piece of software called the DNS resolver (usually built
|
||||
Domain Name System translates Internet domain and host names to IP addresses. DNS
|
||||
implements a distributed database to store name and address information for all
|
||||
public hosts on the Net. DNS assumes IP addresses do not change (i.e., are
|
||||
statically assigned rather than dynamically assigned). The DNS database resides
|
||||
on a hierarchy of special-purpose servers. When visiting a Web site or other device
|
||||
on the Net, a piece of software called the DNS resolver (usually built
|
||||
into the network operating system) first contacts a DNS server to determine the server's IP
|
||||
address. If the DNS server does not contain the needed mapping, it will in turn forward the
|
||||
request to a DNS server at the next higher level in the hierarchy. After potentially several
|
||||
forwarding and delegation messages are sent within the DNS hierarchy, the IP address for the
|
||||
given host eventually is delivered to the resolver. DNS also includes support for caching requests
|
||||
and for redundancy. Most network operating systems allow one to enter the IP addresses of
|
||||
primary, secondary, and tertiary DNS servers, each of which can service initial requests from
|
||||
clients. Many ISPs maintain their own DNS servers and use DHCP to automatically assign the
|
||||
addresses of these servers to dial-in clients, so most home users need not be aware of the
|
||||
details behind DNS configuration. Registered domain names and addresses must be renewed
|
||||
periodically, and should a dispute occur between two parties over ownership of a given name,
|
||||
such as in trademarking, ICANN's Uniform Domain-Name Dispute-Resolution Policy can be invoked.
|
||||
Also known as Domain Name System, Domain Name Service, Domain Name Server.
|
||||
given host eventually is delivered to the resolver. DNS also includes support for caching
|
||||
requests and for redundancy. Most network operating systems allow one to enter the
|
||||
IP addresses of primary, secondary, and tertiary DNS servers, each of which can service
|
||||
initial requests from clients. Many ISPs maintain their own DNS servers and use DHCP
|
||||
to automatically assign the addresses of these servers to dial-in clients, so most
|
||||
home users need not be aware of the details behind DNS configuration. Registered
|
||||
domain names and addresses must be renewed periodically, and should a dispute occur
|
||||
between two parties over ownership of a given name, such as in trademarking, ICANN's
|
||||
Uniform Domain-Name Dispute-Resolution Policy can be invoked. Also known as Domain
|
||||
Name System, Domain Name Service, Domain Name Server.
|
||||
|
||||
environment variable
|
||||
A variable that is available to any program that is started by the shell.
|
||||
|
||||
ESD
|
||||
Enlightened Sound Daemon. This program is designed to mix together several digitized audio streams
|
||||
for playback by a single device.
|
||||
|
||||
filesystem
|
||||
The methods and data structures that an operating system uses to keep track of files on a
|
||||
disk or partition; the way the files are organized on the disk. Also used to describe a
|
||||
partition or disk that is used to store the files or the type of the filesystem.
|
||||
|
||||
FSSTND
|
||||
Often the group, which creates the Linux File System Structure document, or the document itself,
|
||||
is referred to as the 'FSSTND'. This is short for "file system standard". This document has
|
||||
helped to standardize the layout of file systems on Linux systems everywhere. Since the original
|
||||
release of the standard, most distributors have adopted it in whole or in part, much to the benefit
|
||||
of all Linux users.
|
||||
|
||||
GUI
|
||||
Graphical User Interface. The use of pictures rather than just words to represent the input and
|
||||
output of a program. A program with a GUI runs under some windowing system (e.g. The X Window
|
||||
System, Microsoft Windows, Acorn RISC OS, NEXTSTEP). The program displays certain icons, buttons,
|
||||
dialogue boxes etc. in its windows on the screen and the user controls it mainly by moving a pointer
|
||||
on the screen (typically controlled by a mouse) and selecting certain objects by pressing buttons
|
||||
on the mouse while the pointer is pointing at them. Though Apple Computer would like to claim they
|
||||
invented the GUI with their Macintosh operating system, the concept originated in the early 1970s
|
||||
at Xerox's PARC laboratory.
|
||||
Graphical User Interface. The use of pictures rather than just words to represent the input and output of a program. A program with a GUI runs under some windowing system (e.g.
|
||||
The X Window System, Microsoft Windows, Acorn RISC OS, NEXTSTEP). The program displays
|
||||
certain icons, buttons, dialogue boxes etc. in its windows on the screen and the user
|
||||
controls it mainly by moving a pointer on the screen (typically controlled by a mouse) and
|
||||
selecting certain objects by pressing buttons on the mouse while the pointer is pointing
|
||||
at them. Though Apple Computer would like to claim they invented the GUI with their
|
||||
Macintosh operating system, the concept originated in the early 1970s at Xerox's PARC
|
||||
laboratory.
|
||||
|
||||
hard link
|
||||
A directory entry, which maps a filename to an inode, number. A file may have multiple names or
|
||||
hard links. The link count gives the number of names by which a file is accessible. Hard links
|
||||
do not allow multiple names for directories and do not allow multiple names in different filesystems.
|
||||
A directory entry, which maps a filename to an inode, number. A file may have multiple
|
||||
names or hard links. The link count gives the number of names by which a file is
|
||||
accessible. Hard links do not allow multiple names for directories and do not allow
|
||||
multiple names in different filesystems.
|
||||
|
||||
init
|
||||
'init' process is the first user level process started by the kernel. init has many important
|
||||
duties, such as starting getty (so that users can log in), implementing run levels, and taking
|
||||
care of orphaned processes. This chapter explains how init is configured and how you can make
|
||||
use of the different run levels. init is one of those programs that are absolutely essential to
|
||||
the operation of a Linux system, but that you still can mostly ignore. Usually, you only need
|
||||
to worry about init if you hook up serial terminals, dial-in (not dial-out) modems, or if you
|
||||
want to change the default run level. When the kernel has started (has been loaded into memory,
|
||||
has started running, and has initialized all device drivers and data structures and such), it
|
||||
finishes its own part of the boot process by starting a user level program, init. Thus, init
|
||||
is always the first process (its process number is always 1). The kernel looks for init in a
|
||||
few locations that have been historically used for it, but the proper location for it is
|
||||
/sbin/init. If the kernel can't find init, it tries to run /bin/sh, and if that also fails,
|
||||
the startup of the system fails. When init starts, it completes the boot process by doing a
|
||||
number of administrative tasks, such as checking filesystems, cleaning up /tmp, starting various
|
||||
services, and starting a getty for each terminal and virtual console where users should be able
|
||||
to log in. After the system is properly up, init restarts getty for each terminal after a user
|
||||
has logged out (so that the next user can log in). init also adopts orphan processes: when a
|
||||
process starts a child process and dies before its child, the child immediately becomes a child
|
||||
of init. This is important for various technical reasons, but it is good to know it, since it
|
||||
makes it easier to understand process lists and process tree graphs. init itself is not allowed
|
||||
to die. You can't kill init even with SIGKILL. There are a few variants of init available. Most
|
||||
Linux distributions use sysvinit (written by Miquel van Smoorenburg), which is based on the
|
||||
System V init design. The BSD versions of Unix have a different init. The primary difference is
|
||||
run levels: System V has them, BSD doesn't.
|
||||
'init' process is the first user level process started by the kernel. init has many
|
||||
important duties, such as starting getty (so that users can log in), implementing
|
||||
run levels, and taking care of orphaned processes. This chapter explains how init
|
||||
is configured and how you can make use of the different run levels. init is one of
|
||||
those programs that are absolutely essential to the operation of a Linux system,
|
||||
but that you still can mostly ignore. Usually, you only need to worry about init
|
||||
if you hook up serial terminals, dial-in (not dial-out) modems, or if you want to
|
||||
change the default run level. When the kernel has started (has been loaded into memory,
|
||||
has started running, and has initialized all device drivers and data structures and
|
||||
such), it finishes its own part of the boot process by starting a user level program,
|
||||
init. Thus, init is always the first process (its process number is always 1). The
|
||||
kernel looks for init in a few locations that have been historically used for it,
|
||||
but the proper location for it is /sbin/init. If the kernel can't find init, it
|
||||
tries to run /bin/sh, and if that also fails, the startup of the system fails.
|
||||
When init starts, it completes the boot process by doing a number of administrative
|
||||
tasks, such as checking filesystems, cleaning up /tmp, starting various services,
|
||||
and starting a getty for each terminal and virtual console where users should be able
|
||||
to log in. After the system is properly up, init restarts getty for each terminal
|
||||
after a user has logged out (so that the next user can log in). init also adopts
|
||||
orphan processes: when a process starts a child process and dies before its child,
|
||||
the child immediately becomes a child of init. This is important for various
|
||||
technical reasons, but it is good to know it, since it makes it easier to understand
|
||||
process lists and process tree graphs. init itself is not allowed to die. You can't
|
||||
kill init even with SIGKILL. There are a few variants of init available. Most
|
||||
Linux distributions use sysvinit (written by Miquel van Smoorenburg), which is based
|
||||
on the System V init design. The BSD versions of Unix have a different init. The
|
||||
primary difference is run levels: System V has them, BSD doesn't.
|
||||
|
||||
inode
|
||||
An inode is the address of a disk block. When you see the inode information through ls, ls
|
||||
|
|
Loading…
Reference in New Issue