Know thyubuntu


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Know thyubuntu

  1. 1. Login to EditUbuntu Documentation > Community Documentation > KnowThyUbuntuKnowThyUbuntuIntroduction 目录 1. IntroductionThis document attempts to give a user-oriented panoramic of the 2. The Boot Processarchitecture and functioning of an Ubuntu system. It does not provide 3. The Linux Systeminstructions to accomplish any specific tasks, although it will hopefully 4. The Init Processgive you the knowledge to be able to find your own way around the 5. The X Window Server 6. The Display Managerbasic components of the system. 7. The Desktop Environment 1. The Graphical Interface LibrariesThe Boot Process 2. The Sound System 3. Other ServicesWhen your computer is powered on, it starts executing a program that isfound in a persistent memory storage (for instance a ROM chip). Thisbooting firmware (which, on x86 machines, is called the BIOS) can initialize some subsystems that are needed for theproper functioning of your computer; in particular, it has the ability to read data from a mass storage device, such as ahard drive.Thanks to this fact, the boot firmware can load off program code from the hard drive into the main storage (RAM), andinstruct the system processor (CPU) to pass control to it and execute it.There are conventions as to where the firmware is expected to find this piece of code: on x86 machines, for example, it mustreside in the drives master boot record (MBR), which is the first 512-bytes sector of the drive. The program that is foundthere is usually a first-stage bootloader.This bootloader needs to know where to find, and how to start, a proper operating system, or at least a second-stagebootloader. On Ubuntu, the standard first-stage bootloader is a program called GRUB, which can start a few operatingsystems (among which Linux) directly, without calling other intermediate bootloaders.GRUB (Grand Unified Boot-Loader) is in reality quite a complex program, and it cannot fit into the 512 bytes provided bythe boot sector. Instead, it has its own second-stage loader, which resides on an ordinary partition; in fact, the first-stage partof GRUB includes mini-drivers for a few standard filesystems, allowing it to read its second-stage code and configurationdata as ordinary files stored in the operating systems standard directory structure. The GRUB configuration file is, onUbuntu, located in /boot/grub/menu.lst.When GRUBs second stage has been loaded, it proceeds to load an operating system (or present a choice of systems to theuser) according to the contents of its configuration file. After this, control passes to the Linux kernel, which resides in the filepointed to by the /vmlinuz symbolic link.The Linux SystemLinux is what is normally called a "kernel" in computing; its purpose is to supervise the functioning of the system, by givingand taking control of the CPU to and from user programs, and regulating access to the subsystems (main storage, massstorage, various peripherals) that programs can access.Any modern CPU has a distinction between unprivileged and privileged modes of operation. Code that runs in a privilegedmode is a supervisor that has the ability make unprivileged code execute, while still restricting its possible behaviors: forinstance, it can decide which parts of the main storage are accessible to the unprivileged program, instructing a part of theCPU (the MMU) to ignore any attempt to reach "forbidden" memory locations and to return control to the supervisor assoon as such an attempt is made.The Linux kernel is the part of the Ubuntu system that runs in privileged mode on the CPU.Linux is considered a monolithic kernel: this means that, rather than just supplying the very basic functions that allowindependent programs (processes or tasks) to operate and coordinate with one another, it also directly provides many
  2. 2. higher-level abstraction, such as filing systems, networking layers or device drivers.The many parts that compose the Linux kernel have been subdivided into modules, which can reside either inside the Linuxcore kernel image (the file pointed to by /vmlinuz, or as separate files in the /lib/modules/ directory. In this latter case,the kernel is able to load and unload modules dynamically, so that parts of the kernel are only present in the systems mainstorage when they are actually required.The only Linux modules that must reside inside the core image are those needed during the boot process; specifically, thefilesystem handlers are required to be available, in order for the kernel to be able to load further modules from the disk.In Ubuntu, since the user is able to select among a number of different filesystems for the boot partition, the core image onlycontains what is needed to parse a small filesystem image, located in the file linked to by /initrd.img, which is read intoRAM and contains the filesystem handlers and other core modules.Linux publishes system calls to applications to allow them to make use of the services it provides. Device drivers, inparticular, are typically accessed via filesystem calls, and the peripherals they control are represented by the special files thatare found in the /dev/ directory: they can be read from and written to like other files, although in addition to that theynormally also offer means to set and get device parameters.Other means to interact with Linux using only filesystem-type calls are the /sys/ and /proc/ directories, which mount"virtual" filesystems whose files contain information about the current system state.The Init ProcessAfter Linux has completed its initial setup (which can take some seconds, as subsystems are probed and initialized), it loadsthe first non-kernel program into memory (which is, by default, expected to reside in the /sbin/init file); this becomes thefirst userland process, and is given Process ID number 1.In Linux, every process must have a loaded parent process, which is the process which originally spawned (or, in Unix terms,forked) it. The only exception to this rule is process 1, i.e. Init. When Init stops executing, Linux halts the system.The version of Init that Ubuntu 6.10 uses is called upstart, and replaces the older sysvinit that is found in previous versions.What upstart is instructed to do upon its invocation is described by the contents of the /etc/event.d directory; sysvinit, onthe other hand, used a single file called /etc/inittab.No matter what the flavor of Init, it will execute some of the scripts that are in the /etc/init.d directory: each of thisscripts initializes a specific service, and new scripts will be added when you install some daemon packages (i.e. programsthat run in the background to provide services).Ultimately, Init will run the script that starts a display manager (e.g. /etc/init.d/gdm for the Gnome Display Manager, or/etc/init.d/kdm for the KDE Display Manager), which is responsible for all further graphical interaction with the user.The X Window ServerFor the display manager to be able to present any kind of graphical interface to the user, it needs some means to access thegraphics subsystem.The Linux kernel only provides limited means to draw to the screen; what is used for the graphical interface is, instead, auserland daemon called the X window server. X can access the graphics cards hardware either directly, using its ownloadable modules for driving the various different cards that are available on the market, or it can use the kernel-providedgraphics facilities, known as the framebuffer. The former approach is the one normally used.The X server accepts requests from client applications to create windows, which are (normally rectangular) "virtual screens"that the client program can draw into. Windows are then composed on the actual screen by the X server (or by a separatecomposite manager) as directed by the window manager, which usually communicates with the user via graphical controlssuch as buttons and draggable titlebars and borders. A separate window decorator is sometimes used to render theseobjects to the screen, and to react to user actions and report them to the window manager.The protocol that client applications use to communicate with the X server can be estabilished over various differentchannels, such as Unix domain sockets or TCP connections. This allows clients and the server to reside on different physicalmachines.The Display Manager
  3. 3. When the display manager is run by Init, it starts an X server, and registers as a client application to it. It can then proceed toidentify and authenticate the local user and, if authentication succeeds, start a user session.From this point onwards, programs are started under the identity of the user who has logged in; in contrast, the Init process,the display manager and the X server run under a special user identity (called superuser or root) that is granted specialprivileges by the kernel, since it must be able to control parts of the system that normal users should not be able to access.This user/superuser distinction should, however, not be confused with the similar distinction that has been made betweenprivileged ("kernel mode") and unprivileged ("userland") CPU operating modes: processes that run as the superuser (i.e.processes running as root) still run in userland, but are allowed access to kernel system calls that other processes aredenied.Among the programs that the display manager starts there is usually a window manager and a shell, that is a graphicalenvironment that presents itself to the user and allow the user to manually start the applications of their choice.The Desktop EnvironmentThe window manager, the window decorator, the shell and application programs should coordinate together to form acoherent desktop environment.The two best known frameworks of programs, interfaces and libraries that are today employed to achieve this are Gnomeand KDE, shipped respectively with the Ubuntu and Kubuntu distributions.These frameworks provide application programming interfaces (APIs) that let applications make use of libraries toaccess the functions provided by the various subsystems: graphics, sound, printers, scanners... and the desktop environmentsown facilities (window managing, clipboards, notification areas, etc.).Efforts to create standard specifications for desktop management interfaces have been underway since a long time,culminating with todays project.The Graphical Interface LibrariesPerhaps the most vital facility provided by the desktop environment to application is a means to compose interactivegraphical interfaces inside windows: on one hand, this relieves the application programmer from "inventing the wheel" everytime an application is written; on the other hand, it helps the user by making interface elements consistent betweenapplications, with a uniformed "look and feel".Historically, applications accessed such GUI toolkits directly, while nowadays most applications only see the desktopenvironments own APIs, and ???? them the task of talking to the GUI toolkit. This allows the desktop environment to takecharge of inter-applications interface needs, such as clipboards, drag-and-drop, etc.The two most common GUI toolkits today are GTK+ and Qt, which are employed by Gnome and KDE respectively.The Sound SystemALSA is the standard sound interface offered by the Linux kernel. ALSA can drive most soundcards on the market, andoffers interfaces that applications can access directly.However, just as the X server approaches the problem of multiple applications accessing the screen concurrently, whileallowing the user to control how to multiplexing of the various applications graphics output should occur (by means of thewindow manager), there is a need to coordinate concurrent access to the sound system, as well as, in some cases, to supportoperation over a network, like the X server allows for video.The Gnome environment currently uses ESD (the Englightened Sound Daemon) to this end, and KDE uses aRtsd (the analogReal time synthesizer daemon). Both products, however, have proven problematic, and are in the process of being replaced.Many applications that access the soundcard offer the user a choice of using ESD, aRtsd, ALSA or even OSS (the driverframework that preceded ALSA), to solve the many compatibility problems that unfortunately have arisen.Other ServicesGnome and KDE both offer APIs to access CUPS, the Common Unix Printing System; for scanning, SANE is thecommonly used backend, which KDE offers an interface to, although many applications access it directly.GNOME and KDE also offer their own filing system abstraction on top of the ones provided by the Linux kernel; they are
  4. 4. called, respectively, GNOME VFS and KIO, and one of their main purposes is to provide userland filesystem-style accessto services that the kernel does not handle, or handles in a more statical manner, such as network transfer protocols.Due to the pervasiveness of multimedia in modern applications there has become a need to create a standard API to handleas much of this as possible. Since the term "multimedia" applies to many different types of file, such as sound, video andgraphics, and these each have different codecs, compression schemes, etc. and may be opened in many ways (for example,through ALSA, ESD, aRtsd, etc.) then for a developer to make, for example, a music player would be a very large task. TheGStreamer framework has been created to handle all of these different operations, which allows application developers toonly talk to one system, GStreamer, and have instant access to anything that GStreamer can handle. This is good for users aswell, since installing a plugin for GStreamer to handle a new format, for example MP3, means that every GStreamer-awareapplication then has access to this new format.Other services that the desktop environment may provide are session management, passwords management, file formatdecoding and conversion, etc.KnowThyUbuntu (2009-08-07 15:46:55由 @[]:starcraft.man编辑) Page History