You are on page 1of 10

Format Of Case Study:

1) Front Page

K. J. Somaiya College of Engineering, Mumbai-77


(Autonomous College Affiliated to University of Mumbai)
Semester: January 2019- May 2019

Case Study
On
Red Hat Linux
Class TY A/B
Subject: Operating System

Incharge Faculty Name: Submitted By:


Group Members
Rahul Jadeja
Hemang Gala
Saud Khan
Ali Hussain

2) Other Pages with Following Topics:

Font selection : Times new Roman


Font Size : 12

 Functions
 History
 Services
 Version
 Architecture
 Different views (user view, system view)
 System calls
 Scheduling Algorithms
 Advantages and disadvantages
 Commercial uses.
 References

3) Last page – Self assessment of each individual student


Sr. Name of Survey of Report Percentage of work done
No student topic formation (Total should be 100%)
Fuctions:

 Portable(Multiplatform)
 Multitasking
 Multi User
 Multiprocessor (SMP) Support
 Multithreading Support
 Virtual Memory
 Hierarchical File System
 Graphical User Interface (X Window System, Wayland)
 Wide Hardware Support
 Dynamically Linked Shared Libraries as well as Static Libraries
 POSIX Compliant (Almost)
 Multiple Virtual Consoles
 Multitple Filesystem Support
 Multiple Networking Protocols (TCP/IP, IPX/SPX, Appletalk, AX.25)
 Shell
 Strong Security Model
 Open Source

History:

Red Hat Enterprise Linux is the product of a U.S. company called Red Hat, Inc., based in
Raleigh, North Carolina near the campus of NC State University. The company was founded in
the mid 1990s when Marc Ewing and Bob Young merged two companies.

In 1993 Bob Young created a company called ACC Corporation that he says he ran from his
wife’s “sewing closet”. The name ACC was intended to represent a catalog business but was also
an abbreviation of a small business his wife ran called Antiques and Collectables of Connecticut.
Amongst the items sold through the ACC catalog business were Linux CDs and related open
source software.

Around the same time Marc Ewing had created his own Linux distribution which he named Red
Hat Linux (after his propensity to wear a red hat).

In 1995, ACC acquired Red Hat and adopted the name Red Hat, Inc. Red Hat went public in
1999 making both owners fabulously wealthy.

Early releases of Red Hat Linux were shipped to customers on floppy disks and CDs (this, of
course, predated the widespread availability of broadband internet connections). When users
encountered problems with the software they could contact Red Hat only by email. In fact, Bob
Young often jokes that this was effective in limiting support requests since by the time a
customer realized they needed help, their computer was usually inoperative and therefore
unavailable to be used to send an email message seeking assistance from Red Hat’s support
team.

In later years Red Hat provided better levels of support tied to paid subscriptions (and you can
now get phone support 24 hours a day).

Red Hat Enterprise Linux 6 is the latest commercial offering from Red Hat and is targeted at
corporate, mission critical installations. It is an open source product in that you can download the
source code free of charge and build the software yourself if you wish to do so (a task not to be
undertaken lightly) but if you wish to download a pre-built binary version of the software you
have to buy a maintenance subscription which also provides you with support and updates.

Red Hat also sponsors the Fedora Project. The goal of this project is to provide access to a free
Linux operating system (in both source and binary distributions) in the form of Fedora Linux.
Fedora also acts as a proving ground for new features that eventually are adopted into the Red
Hat Enterprise Linux operating system family.

Services:

SYSTEMD
Systemd is a system and service manager for Linux operating systems. It is designed to be
backwards compatible with SysV init scripts, and provides a number of features such as parallel
startup of system services at boot time, on-demand activation of daemons, or dependency-based
service control logic. In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init
system.

SHUTTING DOWN, SUSPENDING, AND HIBERNATING THE SYSTEM


In Red Hat Enterprise Linux 7, the systemctl utility replaces a number of power management
commands used in previous versions of the Red Hat Enterprise Linux system. The commands
listed in Table 10.8, “Comparison of Power Management Commands with systemctl” are still
available in the system for compatibility reasons, but it is advised that you use systemctl when
possible.

10.5. CONTROLLING SYSTEMD ON A REMOTE MACHINE

In addition to controlling the systemd system and service manager locally, the systemctl utility
also allows you to interact with systemd running on a remote machine over the SSH protocol.
Provided that the sshd service on the remote machine is running, you can connect to this machine
by running the systemctl command with the --hostor -H command line option:

10.6. CREATING AND MODIFYING SYSTEMD UNIT FILES

A unit file contains configuration directives that describe the unit and define its behavior.
Several systemctlcommands work with unit files in the background. To make finer adjustments,
system administrator must edit or create unit files manually lists three main directories.
Architecture
Scheduling Algorithms:

EARLIEST DEADLINE FIRST (EDF) SCHEDULING ALGORITHM

Earliest deadline first (EDF) is dynamic priority scheduling algorithm for real time embedded
systems. Earliest deadline first selects a task according to its deadline such that a task with
earliest deadline has higher priority than others. It means priority of a task is inversely
proportional to its absolute deadline. Since absolute deadline of a task depends on the current
instant of time so every instant is a scheduling event in EDF as deadline of task changes with
time. A task which has a higher priority due to earliest deadline at one instant it may have low
priority at next instant due to early deadline of another task. EDF typically executes in
preemptive mode i.e. currently executing task is preempted whenever another task with earliest
deadline becomes active. Consider 3 periodic processes scheduled on a preemptive uniprocessor.
The execution times and periods are as shown in the following table:

Process Timing Data

Process Execution Time Period

P1 1 8

P2 2 5

P3 4 10

In this example, the units of time may be considered to be schedulable time slices. The deadlines
are that each periodic process must complete within its period.

EDF is an optimal algorithm which means if a task set is feasible then it is surely scheduled by
EDF. Another thing is that EDF does not specifically take any assumption on periodicity of tasks
so it is independent of Period of task and therefore can be used to schedule aperiodic tasks as
well. If two tasks have same absolute deadline choose one of them randomly.
COMPLETELY FAIR ALGORITHM

The data structure used for the scheduling algorithm is a red-black tree in which the nodes are
scheduler-specific sched_entity structures. These are derived from the general task_struct
process descriptor, with added scheduler elements.

The nodes are indexed by processor "execution time" in nanoseconds.[3]

A "maximum execution time" is also calculated for each process. This time is based upon the idea
that an "ideal processor" would equally share processing power amongst all processes. Thus, the
maximum execution time is the time the process has been waiting to run, divided by the total
number of processes, or in other words, the maximum execution time is the time the process
would have expected to run on an "ideal processor".

When the scheduler is invoked to run a new process, the operation of the scheduler is as follows:

1. The leftmost node of the scheduling tree is chosen (as it will have the lowest spent
execution time), and sent for execution.
2. If the process simply completes execution, it is removed from the system and scheduling
tree.
3. If the process reaches its maximum execution time or is otherwise stopped (voluntarily or
via interrupt) it is reinserted into the scheduling tree based on its new spent execution
time.
4. The new leftmost node will then be selected from the tree, repeating the iteration.

If the process spends a lot of its time sleeping, then its spent time value is low and it
automatically gets the priority boost when it finally needs it. Hence such tasks do not get less
processor time than the tasks that are constantly running.

A Process Scheduler schedules different processes to be assigned to the CPU based on particular
scheduling algorithms. There are six popular process scheduling algorithms which we are going
to discuss in this chapter −

 First-Come, First-Served (FCFS) Scheduling


 Shortest-Job-Next (SJN) Scheduling
 Priority Scheduling
 Shortest Remaining Time
 Round Robin(RR) Scheduling
 Multiple-Level Queues Scheduling

These algorithms are either non-preemptive or preemptive. Non-preemptive algorithms are


designed so that once a process enters the running state, it cannot be preempted until it completes
its allotted time, whereas the preemptive scheduling is based on priority where a scheduler may
preempt a low priority running process anytime when a high priority process enters into a ready
state.
First Come First Serve (FCFS)

 Jobs are executed on first come, first serve basis.


 It is a non-preemptive, pre-emptive scheduling algorithm.
 Easy to understand and implement.
 Its implementation is based on FIFO queue.
 Poor in performance as average wait time is high.

Wait time of each process is as follows −

Process Wait Time : Service Time - Arrival Time

P0 0-0=0

P1 5-1=4

P2 8-2=6

P3 16 - 3 = 13

Average Wait Time: (0+4+6+13) / 4 = 5.75

Round Robin Scheduling

 Round Robin is the preemptive process scheduling algorithm.


 Each process is provided a fix time to execute, it is called a quantum.
 Once a process is executed for a given time period, it is preempted and other process
executes for a given time period.
 Context switching is used to save states of preempted processes.
Wait time of each process is as follows −

Process Wait Time : Service Time - Arrival Time

P0 (0 - 0) + (12 - 3) = 9

P1 (3 - 1) = 2

P2 (6 - 2) + (14 - 9) + (20 - 17) = 12

P3 (9 - 3) + (17 - 12) = 11

Average Wait Time: (9+2+12+11) / 4 = 8.5

Versions:
•References

https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/7/html/system_administrators_guide

https://en.m.wikipedia.org/wiki/Red_Hat_Linux

https://searchservervirtualization.techtarget.com/tip/Red-Hat-Enterprise-Linux-virtualization-
architecture

http://fedoraproject.org/wiki/History_of_Red_Hat_Linux

You might also like