Unit 10: Integrated Capstone — OS Internals Portfolio & Career Launchpad

An interactive tool that lets users input process details (arrival time, burst time, priority) and visualizes how different scheduling algorithms — FCFS, SJF (Preemptive & Non-Preemptive), Priority, and Round Robin — allocate the CPU. Displays animated Gantt charts, calculates average waiting time, turnaround time, and response time. Allows side-by-side comparison of algorithms.

Option A: Python + tkinter (desktop GUI) — best for beginners
Option B: HTML + CSS + JavaScript (web app) — best for GitHub Pages deployment
Libraries: Canvas API for Gantt chart rendering, Chart.js for comparison graphs

Clean code structure, proper algorithm implementation, visual output, edge case handling (same arrival time, zero burst time), and a professional README with screenshots.

Markdown
# CPU Scheduler Visualizer 🖥️

## About
Interactive CPU scheduling algorithm visualizer built for
my Operating Systems course. Compare FCFS, SJF, Priority,
and Round Robin with animated Gantt charts.

## Features
- ✅ 4 scheduling algorithms (FCFS, SJF, Priority, RR)
- ✅ Animated Gantt chart visualization
- ✅ Average waiting time & turnaround time calculation
- ✅ Side-by-side algorithm comparison
- ✅ Adjustable time quantum for Round Robin
- ✅ Responsive design (works on mobile)

## Tech Stack
HTML5 | CSS3 | Vanilla JavaScript | Canvas API

## Live Demo
🔗 [Try it here](https://yourusername.github.io/cpu-scheduler/)

## Screenshots
![Gantt Chart](screenshots/gantt.png)
![Comparison](screenshots/compare.png)

## How to Run Locally
```bash
git clone https://github.com/yourusername/cpu-scheduler.git
cd cpu-scheduler
open index.html
```

## Algorithm Details
| Algorithm | Preemptive | Starvation | Complexity |
|-----------|-----------|------------|------------|
| FCFS      | No        | No         | O(n)       |
| SJF       | Both      | Yes        | O(n²)      |
| Priority  | Both      | Yes        | O(n²)      |
| RR        | Yes       | No         | O(n)       |

## Author
Your Name — BCA Student | OS Enthusiast
📧 your.email@gmail.com | 🔗 LinkedIn

A GUI-based simulator that implements the Banker's Algorithm for deadlock avoidance. Users input the number of processes, resource types, allocation matrix, maximum matrix, and available resources. The tool determines if the system is in a safe state, displays the safe sequence, and allows users to simulate resource requests to see if they can be granted safely.

Option A: Python + tkinter — matrix input forms, coloured safe/unsafe indicators
Option B: HTML + CSS + JavaScript — deployable to GitHub Pages
Data structures: 2D arrays for Allocation, Max, Need matrices

Correct implementation of the safety algorithm, clean matrix display, ability to handle edge cases (all resources allocated, single process), and clear step-by-step output showing how the safe sequence is found.

Markdown
# Banker's Algorithm Simulator 🏦

## About
Visual simulator for the Banker's Algorithm (deadlock
avoidance). Input allocation & max matrices, check safe
state, and simulate resource requests.

## Features
- ✅ Safe/Unsafe state detection
- ✅ Safe sequence display with step-by-step trace
- ✅ Resource request simulation
- ✅ Dynamic process/resource count
- ✅ Color-coded matrix display
- ✅ Export results as text

## How It Works
1. Enter number of processes and resource types
2. Fill Allocation and Maximum matrices
3. Enter Available resources vector
4. Click "Check Safety" → see safe sequence
5. Simulate a request → see if it's granted

## Screenshots
![Safe State](screenshots/safe.png)
![Request Simulation](screenshots/request.png)

## Author
Your Name — BCA Student | OS Portfolio Project

A tool that compares FIFO, LRU, and Optimal page replacement algorithms. Users input a reference string and the number of frames. The tool shows step-by-step page table updates, highlights page hits (green) and page faults (red), and displays a comparison chart showing total page faults for each algorithm.

HTML + CSS + JavaScript — ideal for web deployment
Uses DOM manipulation for step-by-step animation, CSS transitions for visual feedback

Correct FIFO/LRU/Optimal logic, clear visual differentiation between hits and faults, proper handling of varying frame sizes, and Belady's anomaly demonstration for FIFO.

Markdown
# Page Replacement Algorithm Comparator 📄

## About
Compare FIFO, LRU, and Optimal page replacement with
animated step-by-step visualization. See page hits/faults
in real-time and compare total faults across algorithms.

## Features
- ✅ FIFO, LRU, Optimal algorithms
- ✅ Step-by-step frame animation
- ✅ Hit/Fault counter with color coding
- ✅ Side-by-side comparison chart
- ✅ Belady's anomaly demonstration
- ✅ Custom reference string input

## Live Demo
🔗 [Try it here](https://yourusername.github.io/page-replacement/)

## Author
Your Name — OS Portfolio Project

A comprehensive, printable checklist (PDF + Markdown) for hardening a Linux server. Covers user management, file permissions, firewall configuration, SSH hardening, service management, logging, and intrusion detection. Each item includes the command, what it does, and why it matters.

Markdown (GitHub rendering) + PDF export using Pandoc or browser print
Optionally: HTML version with checkbox interactivity

1. Disable root SSH login  2. Set strong password policy  3. Configure UFW firewall  4. Enable fail2ban  5. Set file permissions (chmod 700 for sensitive dirs)  6. Remove unnecessary packages  7. Enable automatic security updates  8. Configure SSH key-based auth  9. Set up log rotation  10. Enable auditd for system auditing  11. Disable unused network services  12. Set umask to 027  13. Check for SUID/SGID files  14. Configure sysctl for network security  15. Enable SELinux/AppArmor  ... and 15 more items covering kernel hardening, cron job security, backup verification, etc.

This checklist is directly usable as a deliverable for Linux security audit gigs on Fiverr/Upwork. Charge ₹5,000–₹15,000 per audit.

A collection of 10 production-ready shell scripts for common Linux system administration tasks. Each script is documented, tested, and includes usage examples.

1. system-health-check.sh — Monitors CPU, RAM, disk usage, and sends alerts if thresholds exceeded
2. backup-rotate.sh — Automated backup with 7-day rotation and compression
3. user-manager.sh — Create/delete/list users with proper home dirs and permissions
4. log-analyzer.sh — Parse /var/log/syslog for errors, warnings; generate summary report
5. disk-cleanup.sh — Find and remove files older than N days, clear temp files, empty trash
6. service-monitor.sh — Check if critical services (nginx, mysql, ssh) are running; restart if down
7. firewall-setup.sh — Configure UFW rules for web server (allow 80, 443, 22; deny rest)
8. file-permission-audit.sh — Scan for world-writable files, SUID binaries, and insecure permissions
9. cron-job-manager.sh — List, add, remove cron jobs with a menu-driven interface
10. network-diagnostics.sh — Check connectivity, DNS resolution, open ports, and network interfaces

Bash shell scripting, tested on Ubuntu 22.04 / CentOS 8

A repository of working IPC demonstrations in C, covering pipes (anonymous and named), shared memory, message queues, and signals. Each demo includes a producer/consumer or client/server pair with clear documentation.

C programming language, POSIX APIs (fork, pipe, shmget, msgget, signal), Makefile for compilation

Text
ipc-demos/
├── 01-anonymous-pipe/
│   ├── pipe_demo.c
│   └── README.md
├── 02-named-pipe/
│   ├── fifo_writer.c
│   ├── fifo_reader.c
│   └── README.md
├── 03-shared-memory/
│   ├── shm_producer.c
│   ├── shm_consumer.c
│   └── README.md
├── 04-message-queue/
│   ├── mq_sender.c
│   ├── mq_receiver.c
│   └── README.md
├── 05-signals/
│   ├── signal_handler.c
│   └── README.md
├── Makefile
└── README.md

Markdown
# IPC Demo Repository 🔗

## About
Working demonstrations of all major Inter-Process
Communication mechanisms in C/POSIX. Built as part of
my Operating Systems portfolio.

## IPC Methods Covered
| Method | Files | Use Case |
|--------|-------|----------|
| Anonymous Pipe | pipe_demo.c | Parent-child communication |
| Named Pipe (FIFO) | fifo_writer.c, fifo_reader.c | Unrelated process comm |
| Shared Memory | shm_producer.c, shm_consumer.c | High-speed data sharing |
| Message Queue | mq_sender.c, mq_receiver.c | Structured message passing |
| Signals | signal_handler.c | Async event notification |

## Build & Run
```bash
make all
./01-anonymous-pipe/pipe_demo
```

## Author
Your Name — BCA Student | Systems Programming

An Operating System (OS) is system software that acts as an intermediary between the user and computer hardware. It manages hardware resources and provides services for application programs. The main functions are: (1) Process Management — creating, scheduling, and terminating processes; (2) Memory Management — allocating and deallocating RAM; (3) File System Management — organizing, storing, and retrieving files; (4) I/O Device Management — handling input/output device communication via device drivers; (5) Security & Protection — controlling access to resources and preventing unauthorized use. Examples: Linux, Windows, macOS, Android.

Batch OS — jobs are grouped and processed in batches without user interaction (early IBM mainframes). Multiprogramming OS — multiple programs reside in memory; CPU switches between them when one waits for I/O. Multitasking/Time-sharing OS — CPU time is divided into small quanta; each user/process gets a fair share (Unix, Linux). Real-time OS (RTOS) — guarantees response within strict time limits; used in medical devices, flight systems (VxWorks, FreeRTOS). Distributed OS — manages a group of networked computers as a single system (Google's internal OS). Mobile OS — designed for smartphones with touch, power management (Android, iOS).

A system call is a programmatic interface through which a user-level process requests a service from the operating system kernel. It acts as a gateway between user mode and kernel mode. When a process needs to perform a privileged operation (file I/O, memory allocation, process creation), it makes a system call. Examples: (1) fork() — creates a new child process by duplicating the parent; (2) open() — opens a file and returns a file descriptor; (3) write() — writes data from a buffer to a file descriptor. System calls are typically invoked via wrapper functions in C libraries (glibc).

Multiprogramming keeps multiple programs in main memory simultaneously. When one program is waiting for I/O, the CPU switches to another — maximizing CPU utilization. There is no time-sharing; the CPU stays with a process until it blocks. Multitasking (time-sharing) goes further: the CPU switches between processes at very short intervals (time quanta of 10–100ms), giving each process a fair share of CPU time. This creates the illusion of simultaneous execution for users. Key difference: multiprogramming focuses on CPU utilization, while multitasking focuses on response time and user interactivity. Modern OSes like Linux and Windows use multitasking.

The kernel is the core component of an OS that runs in privileged (kernel) mode and directly manages hardware. Monolithic Kernel: All OS services (file system, device drivers, memory management, networking) run in a single large kernel space. Fast due to no message passing overhead, but a bug in any module can crash the entire system. Example: Linux, Unix. Microkernel: Only essential services (IPC, basic scheduling, memory management) run in kernel space; everything else (file systems, drivers) runs in user space as separate processes. More stable and modular, but slower due to inter-process communication overhead. Example: Minix, QNX. Linux uses a monolithic kernel with loadable modules for flexibility.

A process is a program in execution. It includes the program code (text section), current activity (program counter, registers), stack (function parameters, local variables), data section (global variables), and heap (dynamically allocated memory). A process goes through five states: (1) New — being created; (2) Ready — loaded in memory, waiting for CPU; (3) Running — currently executing on CPU; (4) Waiting/Blocked — waiting for I/O or an event; (5) Terminated — execution completed. The OS scheduler moves processes between Ready and Running states.

The Process Control Block (PCB) is a data structure maintained by the OS for each process. It contains all information needed to manage the process: (1) Process ID (PID) — unique identifier; (2) Process State — current state (ready, running, etc.); (3) Program Counter — address of next instruction; (4) CPU Registers — saved register values during context switch; (5) Memory Management Info — page tables, segment tables, base/limit registers; (6) I/O Status — list of open files, allocated devices; (7) Scheduling Info — priority, scheduling queue pointers; (8) Accounting Info — CPU time used, time limits. The PCB is stored in kernel memory and is crucial for context switching.

A process is an independent execution unit with its own memory space (code, data, heap, stack). A thread is a lightweight unit of execution within a process that shares the process's memory space but has its own stack and registers. Key differences: (1) Processes have separate address spaces; threads share the same address space. (2) Creating a process is expensive (requires memory duplication via fork); creating a thread is cheap. (3) Inter-process communication requires IPC mechanisms (pipes, shared memory); threads communicate directly via shared variables. (4) A crash in one process doesn't affect others; a thread crash can crash the entire process. (5) Processes are managed by the OS; threads can be managed by the OS (kernel threads) or by user-space libraries (user threads).

fork() is a Unix system call that creates a new process by duplicating the calling (parent) process. The new process is called the child process. After fork(), both parent and child execute the same code from the point of the fork() call, but in separate memory spaces. Return values: fork() returns twice — once in the parent (returns child's PID, a positive integer), and once in the child (returns 0). If fork() fails, it returns -1 to the parent. This return value difference allows programmers to write different code paths for parent and child using if-else. The child gets a copy of the parent's data, stack, and heap but has a new PID.

A context switch is the process of saving the state (context) of the currently running process and restoring the state of the next process to be executed. The saved context includes the program counter, CPU registers, memory management info, and I/O state — all stored in the PCB. Context switches are overhead because: (1) The CPU does no useful work during the switch — it's pure administrative overhead. (2) CPU caches become invalid (cache cold start), causing cache misses. (3) TLB (Translation Lookaside Buffer) entries must be flushed. (4) Pipeline must be cleared. A typical context switch takes 1–10 microseconds. Excessive context switching (due to very small time quanta or too many processes) degrades performance significantly.

FCFS (First Come First Served): Non-preemptive, processes served in arrival order. Simple but causes convoy effect — short processes wait behind long ones. SJF (Shortest Job First): Selects the process with smallest burst time. Optimal for minimizing average waiting time but requires knowing burst times in advance (impractical). Can cause starvation of long processes. Priority Scheduling: Each process has a priority; highest priority runs first. Can be preemptive or non-preemptive. Suffers from starvation — solved by aging (gradually increasing priority of waiting processes). Round Robin: Each process gets a fixed time quantum (e.g., 20ms). If not finished, it goes to the back of the ready queue. Fair and responsive (good for time-sharing) but high context switch overhead with small quanta.

The time quantum (time slice) in Round Robin critically affects performance. If quantum is too large (e.g., 1000ms), RR degenerates into FCFS — processes finish within one quantum, so no preemption occurs. Response time increases. If quantum is too small (e.g., 1ms), the CPU spends more time context switching than executing processes — overhead dominates. Optimal quantum: 10–100ms, typically chosen so that 80% of CPU bursts complete within one quantum. Rule of thumb: quantum should be large enough that context switch time is less than 10% of the quantum. In practice, Linux uses the Completely Fair Scheduler (CFS) which dynamically adjusts time slices based on the number of runnable processes.

The convoy effect occurs in FCFS scheduling when a CPU-bound process with a long burst time gets the CPU first, causing all shorter I/O-bound processes to wait behind it — like a slow truck on a single-lane road causing a convoy of cars behind it. This results in very high average waiting time and poor CPU utilization (since I/O-bound processes that could release the CPU quickly are stuck waiting). The convoy effect doesn't happen in SJF (short jobs go first), Priority (based on priority, not arrival), or Round Robin (preemption ensures all processes get CPU time). It's a key reason why FCFS is not used in modern interactive systems.

Starvation (also called indefinite waiting) occurs when a low-priority process never gets CPU time because higher-priority processes keep arriving. It can happen in Priority Scheduling and SJF (a long process may never run if short processes keep arriving). Aging is the solution: the OS gradually increases the priority of processes that have been waiting for a long time. For example, every 15 minutes, increase the priority of all waiting processes by 1. Eventually, even the lowest-priority process will have its priority raised high enough to get scheduled. Linux implements aging in its CFS scheduler by tracking the virtual runtime (vruntime) — processes that have received less CPU time naturally get higher scheduling priority.

In non-preemptive (cooperative) scheduling, once a process gets the CPU, it keeps it until it completes or voluntarily releases it (by blocking for I/O). Simple to implement but poor response time — a long process blocks everything. Examples: FCFS, Non-preemptive SJF. In preemptive scheduling, the OS can forcibly take the CPU from a running process (via a timer interrupt) and give it to another process. Better response time and fairness but requires more complex implementation and context switch overhead. Examples: Round Robin, Preemptive SJF (SRTF), Preemptive Priority. Modern OSes (Linux, Windows) use preemptive scheduling to ensure interactive responsiveness.

A race condition occurs when two or more processes/threads access shared data concurrently, and the final result depends on the order of execution — which is unpredictable. Example: Two threads incrementing a shared counter count = count + 1. If count = 5, both threads read 5, both compute 6, both write 6 — but the correct answer should be 7. This happens because the increment operation is not atomic (it involves read, modify, write). Race conditions cause bugs that are hard to reproduce because they depend on timing. Solution: Use synchronization mechanisms (mutexes, semaphores) to ensure only one thread accesses the critical section at a time.

A critical section is a segment of code where a process accesses shared resources (variables, files, databases) that must not be accessed by other processes simultaneously. The three requirements for a correct critical section solution are: (1) Mutual Exclusion: If process P is executing in its critical section, no other process can enter its critical section. (2) Progress: If no process is in the critical section, the decision of which process enters next cannot be postponed indefinitely — a process that wants to enter should be able to. (3) Bounded Waiting: There must be a limit on how many times other processes can enter their critical sections after a process has requested entry — prevents starvation.

A Mutex (Mutual Exclusion) is a locking mechanism that allows only one thread to access a resource at a time. The thread that locks the mutex must be the one to unlock it (ownership). Think of it as a single key to a bathroom — one person uses it, others wait. A Semaphore is a signaling mechanism with an integer counter. A counting semaphore allows up to N concurrent accesses (e.g., limiting database connections to 10). A binary semaphore (counter = 0 or 1) is similar to a mutex but without ownership — any thread can signal (release) it. Key differences: Mutex has ownership (only the locker can unlock); semaphore has no ownership. Mutex is for mutual exclusion; semaphore is for signaling and resource counting. Mutex is simpler; semaphore is more flexible but prone to misuse.

The Producer-Consumer problem is a classic synchronization problem. A producer process generates data and places it in a shared buffer. A consumer process removes data from the buffer. Constraints: (1) The producer must not add data when the buffer is full — it must wait. (2) The consumer must not remove data when the buffer is empty — it must wait. (3) Access to the buffer must be mutually exclusive. Solution uses three synchronization primitives: a mutex for buffer access, a full semaphore (count of filled slots, initialized to 0), and an empty semaphore (count of empty slots, initialized to buffer size). Producer: wait(empty), wait(mutex), add item, signal(mutex), signal(full). Consumer: wait(full), wait(mutex), remove item, signal(mutex), signal(empty).

Deadlock is a situation where two or more processes are blocked forever, each waiting for a resource held by the other. Example: Process A holds Resource 1 and waits for Resource 2; Process B holds Resource 2 and waits for Resource 1 — neither can proceed. All processes involved are permanently stuck. Starvation is when a process is perpetually denied the resources it needs because other processes keep getting priority. Unlike deadlock, the system is still making progress — just not for the starving process. Example: In priority scheduling, a low-priority process may never run. Key difference: In deadlock, NO involved process makes progress; in starvation, OTHER processes do make progress, but the starved one doesn't. Deadlock implies starvation, but starvation doesn't imply deadlock.

All four conditions must hold simultaneously for a deadlock to occur (Coffman conditions): (1) Mutual Exclusion: At least one resource must be held in a non-sharable mode — only one process can use it at a time. (2) Hold and Wait: A process holding at least one resource is waiting to acquire additional resources held by other processes. (3) No Preemption: Resources cannot be forcibly taken from a process — they must be released voluntarily. (4) Circular Wait: There exists a circular chain of processes, each waiting for a resource held by the next process in the chain. Preventing any one condition prevents deadlock.

The Banker's Algorithm is a deadlock avoidance algorithm that checks if granting a resource request will keep the system in a safe state. It uses three matrices: Allocation (resources currently held by each process), Max (maximum resources each process may need), and Need (Max - Allocation). Plus an Available vector. The safety algorithm: (1) Find a process whose Need ≤ Available. (2) Assume it finishes and release its resources: Available += Allocation. (3) Repeat until all processes finish (safe) or no process can proceed (unsafe). Example: 3 processes, 1 resource type. Available=2, Allocation=[1,1,1], Max=[3,2,2]. Need=[2,1,1]. Process P1 (need 1 ≤ 2) → Available becomes 3 → P2 (need 2 ≤ 3) → Available becomes 4 → P0 (need 2 ≤ 4). Safe sequence: P1→P2→P0.

Prevention: Ensure at least one of the 4 Coffman conditions never holds. Conservative approach — may reduce resource utilization. Examples: require processes to request all resources upfront (eliminates hold-and-wait), impose ordering on resource types (eliminates circular wait). Avoidance: Allow all 4 conditions to be possible but make careful decisions to avoid actually entering a deadlock state. Requires advance knowledge of maximum resource needs. Example: Banker's Algorithm. Detection: Allow deadlocks to occur, then detect and recover. Uses a wait-for graph or resource allocation graph — if a cycle exists, deadlock is detected. Recovery: kill one or more processes, or preempt resources. Detection is used when deadlocks are rare (overhead of prevention/avoidance isn't justified).

A Resource Allocation Graph (RAG) is a directed graph used to describe the state of resource allocation in a system. It has two types of nodes: Process nodes (circles) and Resource nodes (rectangles with dots representing instances). Two types of edges: Request edge (Process → Resource, meaning the process is waiting for the resource) and Assignment edge (Resource → Process, meaning the resource is allocated to the process). Deadlock detection: If the graph contains a cycle and each resource type has only one instance, there IS a deadlock. If resources have multiple instances, a cycle is necessary but not sufficient — need to run the detection algorithm. No cycle → definitely no deadlock.

Once a deadlock is detected, the OS can recover using several methods: (1) Process Termination: Kill all deadlocked processes (drastic but simple), or kill processes one by one until the deadlock cycle is broken (choose victim based on priority, runtime, resources held). (2) Resource Preemption: Forcibly take resources from some deadlocked processes and give them to others. Requires rollback — the preempted process must be restarted or rolled back to a safe checkpoint. Challenges: Selecting the victim (minimize cost), ensuring no starvation (don't always preempt the same process), and determining the rollback point. In practice, most modern systems either use deadlock prevention (e.g., lock ordering in databases) or simply restart the system/process when deadlock is suspected (e.g., database transaction timeout and retry).

Protection is an internal mechanism — it controls access to resources within the system by authorized users and processes. It defines WHO can do WHAT with which resources (e.g., user A can read file X but not write). It assumes users are authenticated and focuses on enforcing policies. Security is a broader concept that includes protection plus defense against external threats — unauthorized access, malware, network attacks, social engineering. Security asks: "How do we verify identity (authentication)? How do we prevent unauthorized access (authorization)? How do we detect and respond to attacks?" Protection is a subset of security. Example: File permissions (chmod) = protection. Firewall blocking hackers = security.

An access matrix is a conceptual model for protection. It's a 2D matrix where rows represent subjects (users, processes) and columns represent objects (files, devices, memory segments). Each cell contains the access rights (read, write, execute, delete) that the subject has for the object. Since the full matrix is usually sparse (most cells are empty), it's implemented in two ways: (1) Access Control Lists (ACLs): Column-based — each object stores a list of (subject, rights) pairs. Used by Linux file permissions and Windows NTFS. (2) Capability Lists: Row-based — each subject holds a list of (object, rights) pairs, like a set of keys. Each approach has trade-offs: ACLs are easy to check per-object; capabilities are easy to check per-subject.

A buffer overflow occurs when a program writes data beyond the boundary of a fixed-size buffer, overwriting adjacent memory. Attackers exploit this to inject malicious code. Example: A C program uses gets(buffer) to read user input into a 64-byte array. An attacker inputs 200 bytes, overwriting the function's return address on the stack with the address of malicious shellcode. When the function returns, it jumps to the attacker's code instead of the caller — giving them control. Prevention: (1) Use safe functions like fgets() instead of gets(). (2) Enable stack canaries (gcc -fstack-protector). (3) Use ASLR (Address Space Layout Randomization). (4) Use non-executable stack (NX bit). Modern OS and compilers include these defenses by default.

Access Control Lists (ACLs): Stored with each object (file). Lists which subjects (users/groups) have which permissions. Example: Linux file permissions -rwxr-xr-- is a simplified ACL — owner has rwx, group has r-x, others have r--. Extended ACLs (setfacl) allow finer-grained control. Advantage: Easy to see and change who has access to a specific file. Disadvantage: Hard to determine all files a user can access. Capability Lists: Stored with each subject (user/process). Lists which objects the subject can access and how. Like a set of keys — the user carries tokens that grant access. Advantage: Easy to see everything a user can access. Disadvantage: Hard to revoke access to a specific object (must find all capabilities for it). Most modern systems use ACLs.

(1) chmod — Changes file permissions. Example: chmod 700 private.txt gives the owner full permissions and removes all access for group and others. Essential for protecting sensitive files. (2) ufw (Uncomplicated Firewall) — Manages firewall rules. Example: ufw allow 22/tcp allows SSH connections; ufw enable activates the firewall. Crucial for server security. (3) passwd — Changes user passwords. Example: passwd -e username forces a user to change their password on next login. Combined with /etc/login.defs for password aging policies. Other important security commands: chown (change ownership), iptables (advanced firewall), fail2ban (brute force protection), ssh-keygen (SSH key generation).

Paging: Physical memory is divided into fixed-size blocks called frames; logical memory is divided into same-size blocks called pages (typically 4KB). A page table maps logical pages to physical frames. Eliminates external fragmentation but may cause internal fragmentation (last page may not be full). OS manages paging — invisible to the programmer. Segmentation: Memory is divided into variable-size segments based on logical units (code segment, data segment, stack segment). Each segment has a base address and limit. Visible to the programmer — matches logical view of a program. Causes external fragmentation (variable sizes leave gaps). Can be combined with paging (segmented paging) — Intel x86 originally used this. Modern systems primarily use paging.

A page fault occurs when a process tries to access a page that is not currently in physical memory (RAM). Steps when a page fault occurs: (1) CPU generates a page fault trap to the OS. (2) OS checks internal table — is it a valid or invalid reference? If invalid → terminate process. (3) If valid but page is on disk: find a free frame in memory. (4) If no free frame: use a page replacement algorithm (FIFO, LRU, Optimal) to select a victim page. If victim is dirty (modified), write it back to disk. (5) Read the required page from disk into the free frame. (6) Update the page table to reflect the new mapping. (7) Restart the instruction that caused the page fault. Page fault handling is expensive (disk I/O is ~10ms vs ~100ns for memory access), so minimizing page faults is critical for performance.

FIFO (First In First Out): Replace the oldest page (first loaded). Simple to implement using a queue. But may remove frequently used pages. Suffers from Belady's anomaly — more frames can lead to more page faults. LRU (Least Recently Used): Replace the page that hasn't been used for the longest time. Based on temporal locality — recently used pages are likely to be used again. Better than FIFO but expensive to implement exactly (needs timestamps or stack). Approximated using reference bits (clock algorithm). Optimal: Replace the page that won't be used for the longest time in the future. Gives minimum page faults but impossible to implement in practice (requires future knowledge). Used as a benchmark to evaluate other algorithms. In practice, LRU or its approximation (clock algorithm) is most commonly used.

Belady's anomaly is the counterintuitive phenomenon where increasing the number of page frames results in MORE page faults, not fewer. It occurs with the FIFO page replacement algorithm. Classic example: Reference string 1,2,3,4,1,2,5,1,2,3,4,5. With 3 frames: 9 page faults. With 4 frames: 10 page faults — one MORE fault despite having an extra frame! This happens because FIFO doesn't consider usage frequency — it blindly removes the oldest page. LRU and Optimal algorithms do NOT suffer from Belady's anomaly because they belong to a class called "stack algorithms" where the set of pages in memory with N frames is always a subset of pages with N+1 frames. This is a favourite interview question — knowing this shows deep understanding.

Thrashing occurs when a system spends more time paging (swapping pages in and out of memory) than executing actual processes. It happens when processes don't have enough frames to hold their working set of pages, causing continuous page faults. Symptoms: CPU utilization drops to near zero while disk activity is at 100%. Causes: Too many processes loaded, insufficient RAM. Prevention: (1) Working Set Model: Monitor each process's working set (set of pages actively used) and ensure it fits in available frames. If total working set exceeds available frames, suspend some processes. (2) Page Fault Frequency (PFF): Monitor page fault rate for each process. If too high → allocate more frames. If too low → reduce frames. (3) Increase RAM or reduce the degree of multiprogramming (fewer concurrent processes).

Contiguous: Each file occupies a contiguous set of blocks on disk. Fast sequential and direct access (just start block + offset). But causes external fragmentation — finding contiguous space becomes difficult as files are created and deleted. File size must be known in advance. Linked: Each block contains a pointer to the next block. No external fragmentation, files can grow dynamically. But direct access is very slow (must traverse from start). A damaged pointer can lose the rest of the file. FAT (File Allocation Table) is an improved version that stores all pointers in a separate table. Indexed: Each file has an index block containing pointers to all its data blocks. Supports direct access without external fragmentation. Wastes space for the index block (especially for small files). Multi-level index or combined scheme (like Unix inodes) handles large files. Most modern file systems use indexed allocation.

An inode (index node) is a data structure in Unix/Linux file systems that stores metadata about a file or directory — everything EXCEPT the file name and data. Each inode has a unique number and contains: (1) File type (regular file, directory, symlink); (2) Permissions (rwx for owner, group, others); (3) Owner UID and Group GID; (4) File size in bytes; (5) Timestamps — access time (atime), modification time (mtime), change time (ctime); (6) Link count (number of hard links); (7) Pointers to data blocks — typically 12 direct pointers, 1 single indirect, 1 double indirect, 1 triple indirect (allows files up to several TB). The filename is stored in the directory entry, which maps the name to the inode number. Use ls -i to see inode numbers.

FCFS: Service requests in arrival order. Fair but high seek time — the head may jump back and forth across the disk. SSTF (Shortest Seek Time First): Service the closest request next. Lower average seek time than FCFS but causes starvation of distant requests. Similar to SJF in CPU scheduling. SCAN (Elevator): Head moves in one direction servicing requests, then reverses. Fair and no starvation. But requests at the edges wait longer. Like an elevator in a building. C-SCAN (Circular SCAN): Head moves in one direction servicing requests, then jumps back to the beginning without servicing and starts again. More uniform wait times than SCAN. Treats the disk as a circular structure. Most modern disk schedulers use variants of SCAN or the Linux CFQ (Completely Fair Queuing) / deadline scheduler.

Journaling is a technique used by file systems to maintain data integrity after a crash (power failure, kernel panic). Before writing actual data to disk, the file system first writes the intended changes to a journal (a dedicated area on disk). If a crash occurs mid-write: on reboot, the file system checks the journal and either completes the pending writes or rolls them back — ensuring the file system remains consistent. Without journaling, a crash could leave the file system in a corrupted state (requiring a full fsck scan, which takes hours on large disks). Types: Metadata journaling (only logs metadata changes — faster, used by ext4 default) and Full journaling (logs both metadata and data — slower but safer). Examples: ext3/ext4 (Linux), NTFS (Windows), HFS+ (macOS).

RAID (Redundant Array of Independent Disks) combines multiple physical disks into a single logical unit for performance, redundancy, or both. RAID 0 (Striping): Data is split across disks for speed. If you have 2 disks, read/write speed doubles. But NO redundancy — if one disk fails, all data is lost. Used for speed-critical, non-essential data. RAID 1 (Mirroring): Data is duplicated on two disks. If one fails, the other has a complete copy. Read speed improves (can read from either disk), write speed stays same (must write to both). Storage efficiency: 50%. Used for critical data (OS drives). RAID 5 (Striping with Parity): Data and parity are striped across 3+ disks. Can tolerate one disk failure (parity allows reconstruction). Good balance of speed, redundancy, and storage efficiency (67-94% depending on disk count). Most popular for servers.

Inter-Process Communication (IPC) is a set of mechanisms that allow processes to exchange data and coordinate their activities. IPC is needed because: (1) Data sharing: Multiple processes may need to work on the same data (e.g., a web server and a database). (2) Modularity: Complex applications are split into cooperating processes (microservices architecture). (3) Parallelism: Distributing work across processes for faster execution. (4) Convenience: A user running multiple programs that need to interact (e.g., piping output from ls to grep). IPC mechanisms include: pipes (anonymous and named/FIFO), shared memory, message queues, sockets, and signals. Choice depends on: speed needed, whether processes are related (parent-child), and whether they're on the same or different machines.

Anonymous Pipes: Unidirectional, only between related processes (parent-child). Created by pipe() syscall. Simple but limited. Example: ls | grep txt. Named Pipes (FIFOs): Have a name in the file system (/tmp/myfifo). Can be used between unrelated processes. Still unidirectional (need two for bidirectional). Shared Memory: Fastest IPC — multiple processes map the same region of physical memory into their address space. No kernel involvement for data transfer (just read/write memory). But requires explicit synchronization (semaphores) to prevent race conditions. Best for large data transfers. Message Queues: Processes send and receive structured messages via a kernel-managed queue. Messages have types for selective reception. Slower than shared memory but provides built-in synchronization and message ordering. Good for structured communication between multiple producers/consumers.

A socket is an endpoint for communication between two processes, either on the same machine or across a network. Identified by an IP address and port number. TCP (Transmission Control Protocol) sockets: Connection-oriented — a reliable, ordered, bidirectional stream. Data arrives in order, without duplicates, with error checking. Used for: web browsing (HTTP), email, file transfer. Overhead: connection setup (3-way handshake), acknowledgements. UDP (User Datagram Protocol) sockets: Connectionless — unreliable, unordered datagrams. Faster and lower overhead than TCP but packets can be lost, duplicated, or arrive out of order. Used for: video streaming, online gaming, DNS queries — where speed matters more than perfect delivery. In OS context, sockets are the primary IPC mechanism for network communication between processes on different machines.

Use Pipes when: (1) Communication is between parent-child processes. (2) Data flow is unidirectional and sequential (like a stream). (3) You want simplicity — pipes handle synchronization automatically (a read blocks if no data is available). (4) Data volume is small to moderate. Example: Shell commands piped together (cat file | sort | uniq). Use Shared Memory when: (1) Speed is critical — shared memory is the fastest IPC mechanism (no kernel copy). (2) Large data volumes need to be shared (e.g., a database buffer pool). (3) Multiple processes need random access to the same data. (4) You're willing to handle synchronization yourself (semaphores, mutexes). Example: A web server sharing session data across worker processes. Trade-off: Pipes are simpler but slower; shared memory is faster but more complex.

A signal is an asynchronous notification sent to a process to notify it of an event. Signals are software interrupts — they interrupt the normal flow of a process. When a signal is received, the process can: (1) Handle it with a custom signal handler function, (2) Ignore it, or (3) Let the default action occur (usually terminate). Examples: (1) SIGKILL (9) — forcefully terminates a process. Cannot be caught or ignored. Used as a last resort: kill -9 PID. (2) SIGTERM (15) — polite termination request. Process can catch it and perform cleanup before exiting. Default signal sent by kill PID. (3) SIGINT (2) — sent when user presses Ctrl+C. Interrupts the foreground process. Can be caught to save work before exiting. Others: SIGSEGV (segmentation fault), SIGALRM (timer), SIGCHLD (child process terminated).

I would design the OS with these core components: (1) Bootloader — initializes hardware, loads the kernel into memory (like GRUB). (2) Kernel — I'd choose a monolithic kernel with loadable modules for performance + flexibility. Core functions: process scheduling (CFS-like algorithm), memory management (demand paging with LRU replacement), and interrupt handling. (3) Process Manager — PCB structures, fork/exec system calls, scheduler with multiple scheduling classes. (4) Memory Manager — virtual memory with paging, page table management, swap space. (5) File System — journaling FS with inode-based indexed allocation. (6) I/O Subsystem — device driver framework, buffering, DMA support. (7) IPC — pipes, shared memory, message queues, sockets. (8) Security Module — user authentication, ACLs, capability-based access control. (9) Shell — command-line interpreter. (10) System Call Interface — user-kernel gateway.

Android is built on top of the Linux kernel, leveraging its features extensively: (1) Process Management: Each Android app runs in its own Linux process with a unique UID — providing process isolation (an app crash doesn't affect others). (2) Memory Management: Uses Linux's virtual memory, OOM (Out of Memory) killer to free RAM by killing low-priority apps when memory is low. (3) Binder IPC: Android's primary IPC mechanism (custom Linux kernel driver) for communication between apps and system services — more efficient than standard pipes for Android's use case. (4) File System: Uses ext4 (internal storage) and FAT/exFAT (SD cards). (5) Security: SELinux (mandatory access control), Linux file permissions, and sandboxing ensure each app is isolated. (6) Networking: Linux TCP/IP stack for WiFi, mobile data. Android adds HAL (Hardware Abstraction Layer) between the kernel and Android framework.

When you type ls -la and press Enter: (1) The shell (bash) reads your input from stdin. (2) Shell parses the command: ls is the command, -la are arguments. (3) Shell searches for the ls binary: checks aliases first, then built-ins, then searches directories in $PATH (/usr/bin/ls). (4) Shell calls fork() to create a child process. (5) In the child process, shell calls exec() (specifically execvp("ls", ["ls", "-la"])) — this replaces the child's code with the ls program. (6) ls makes system calls: opendir(), readdir(), stat() to get directory entries and file metadata. (7) ls writes output to stdout using write() system call. (8) ls exits. (9) Parent shell calls wait() to reap the child, gets exit status. (10) Shell displays the next prompt.

Docker containers leverage several OS concepts: (1) Namespaces (Process Isolation): Linux namespaces give each container its own isolated view of PID (process IDs), network, mount points, hostname, and user IDs — so processes inside a container can't see or affect processes in other containers. (2) cgroups (Resource Management): Control Groups limit and monitor resource usage (CPU, RAM, I/O, network) per container — similar to how an OS allocates resources to processes. (3) Union File System (layered storage): Uses copy-on-write — container images are built in layers (like page sharing in virtual memory). Multiple containers can share base layers, saving disk space. (4) Virtual Networking: Each container gets its own network stack, IP address, and port mappings — OS networking concepts applied at the container level. Containers are NOT virtual machines — they share the host OS kernel, making them much lighter (start in milliseconds vs minutes).

Virtual memory is a memory management technique that gives each process the illusion of having a large, contiguous address space, even if physical RAM is limited. How it works: (1) Each process has a virtual address space (e.g., 4GB on 32-bit systems). (2) Virtual addresses are divided into pages (typically 4KB). Physical memory is divided into frames of the same size. (3) A page table (per process) maps virtual pages to physical frames. The MMU (Memory Management Unit) hardware translates addresses on every memory access. (4) Not all pages need to be in RAM — only the working set. Other pages are stored on disk (swap space). (5) When a process accesses a page not in RAM, a page fault occurs. The OS loads the page from disk into a free frame (using page replacement if needed). (6) The TLB (Translation Lookaside Buffer) caches recent page table entries for speed. Benefits: (a) Process isolation — each process has its own address space. (b) Run programs larger than physical RAM. (c) Memory sharing — multiple processes can share common pages (libraries). (d) Efficient memory allocation — no external fragmentation.

BCA Graduate | OS & Linux Enthusiast | Systems Engineer | Shell Scripting | Open to Opportunities

Text
🔧 Systems-oriented developer with hands-on experience in
Operating Systems internals, Linux administration, and
shell scripting.

🎯 I build tools that visualize OS concepts:
→ CPU Scheduler Visualizer (FCFS, SJF, RR) — live on GitHub Pages
→ Banker's Algorithm Simulator — deadlock avoidance with GUI
→ Page Replacement Comparator — FIFO vs LRU vs Optimal
→ 10+ production-ready shell scripts for system automation

💻 Technical Skills:
• OS Concepts: Process mgmt, memory mgmt, file systems, IPC
• Linux: Ubuntu, CentOS | CLI proficiency | server hardening
• Programming: Python, C, Bash scripting
• Tools: Git, GitHub, Docker (basics), VS Code
• Networking: TCP/IP, sockets, SSH

🏆 Currently seeking: Systems Engineer / DevOps / Linux Admin roles
📍 Location: Open to relocation across India
📧 Reach me at: your.email@gmail.com

Linux, Operating Systems, Shell Scripting, Bash, Python, C Programming, System Administration, Git, GitHub, Docker, Networking, TCP/IP, SQL, Problem Solving, Data Structures

Pin your best GitHub repos and live project demos. Include a screenshot or GIF of your CPU Scheduler Visualizer in action — visual content gets 3× more engagement on LinkedIn.

Text
🖥️ I built a CPU Scheduler Visualizer as part of my
OS studies — and I'm sharing it for free!

It lets you compare FCFS, SJF, Priority, and Round Robin
with animated Gantt charts and performance metrics.

🔗 Live Demo: [your GitHub Pages URL]
📂 Source Code: [your GitHub repo URL]

Built with: HTML, CSS, JavaScript
What I learned: How scheduling algorithms trade off between
fairness, throughput, and response time.

#OperatingSystems #GitHub #OpenSource #BCA #SystemsEngineering

☐ 1. Can you explain all 4 CPU scheduling algorithms with pros/cons and examples?

☐ 2. Can you solve a Banker's Algorithm problem on paper in under 10 minutes?

☐ 3. Can you write 5+ shell scripts from memory (backup, monitoring, user mgmt)?

☐ 4. Can you explain paging vs segmentation and draw a page table?

☐ 5. Can you describe 4 IPC mechanisms and when to use each?

☐ 6. Is your GitHub portfolio complete with READMEs, screenshots, and live demos?

☐ 7. Can you explain what happens when you run a Linux command (fork → exec → wait)?

☐ 8. Can you list and explain the 4 deadlock conditions from memory?

☐ 9. Is your LinkedIn profile updated with OS projects and relevant keywords?

☐ 10. Have you posted at least 1 freelance gig related to your OS skills?

Score 8+/10: You're interview-ready! Start applying. 5–7: Almost there — fill the gaps this week. Below 5: Revisit Units 1–9 and build the missing projects.

Model Answer: My ideal OS portfolio would include: (1) CPU Scheduler Visualizer — demonstrates understanding of process scheduling and algorithm design; deployed on GitHub Pages for live interaction. (2) Banker's Algorithm Simulator — shows ability to implement deadlock avoidance with proper matrix operations. (3) Page Replacement Comparator — proves understanding of virtual memory and page management. (4) Linux Security Hardening Checklist — demonstrates practical server administration knowledge; directly usable by employers. (5) Shell Script Automation Bundle (10 scripts) — shows real-world automation skills that DevOps teams need daily. (6) IPC Demo Repository — demonstrates system-level programming skills in C with pipes, shared memory, and message queues. Each project should have a clean README with screenshots, proper documentation, and a live demo link where possible. This portfolio covers: theory (algorithms), practical skills (scripting, admin), and system programming — the complete trifecta that systems engineering roles require.

Model Answer: (1) FCFS is like a bank queue — whoever arrives first gets served first, regardless of how long their transaction takes. If someone ahead of you is depositing 500 checks, you wait. Simple and fair but slow for people with quick tasks (convoy effect). (2) SJF is like an express checkout at Big Bazaar — if you have fewer items, you go to the express counter and get done faster. Minimizes average waiting but people with full trolleys (long jobs) might wait forever (starvation). (3) Round Robin is like sharing a cricket bat during practice — each player gets 5 minutes at the crease (time quantum), then passes the bat to the next person. Everyone gets a fair chance. If you're a good batsman, you'll need multiple turns to finish your practice (context switch overhead), but no one is left out. This is what modern OSes use for interactive systems because it gives good response time.

Model Answer: When a process accesses a page not in RAM: (1) The CPU's MMU checks the page table, finds the valid/invalid bit is set to "invalid" — triggers a page fault trap. (2) The OS trap handler verifies: is this a valid virtual address? If invalid (beyond process's address space) → segmentation fault, terminate process. (3) If valid: the OS locates the page on disk (swap space or file system). (4) OS finds a free frame in physical memory. If no free frames exist, run a page replacement algorithm (LRU/FIFO/Optimal) to choose a victim page. (5) If the victim page is dirty (modified), write it back to disk first. (6) Load the required page from disk into the selected frame (disk I/O — takes ~10ms). (7) Update the page table entry: set frame number, change valid bit to "valid." (8) Restart the instruction that caused the fault. The process continues as if the page was always in memory. This entire process is called "demand paging" — pages are loaded only when demanded, saving RAM.

Model Answer: (1) Disable root SSH login — edit /etc/ssh/sshd_config, set PermitRootLogin no. (2) Enable SSH key-based authentication — disable password auth, use ssh-keygen + authorized_keys. (3) Configure UFW firewall — allow only ports 22 (SSH), 80 (HTTP), 443 (HTTPS); deny all others. (4) Install fail2ban — automatically bans IPs after 5 failed login attempts. (5) Enable automatic security updates — apt install unattended-upgrades. (6) Set strong password policy — edit /etc/login.defs, set minimum length, complexity. (7) Remove unnecessary packages — apt autoremove, disable unused services. (8) Configure file permissions — chmod 700 for sensitive directories, remove world-writable files. (9) Enable SELinux/AppArmor — mandatory access control beyond traditional permissions. (10) Set up log monitoring — configure rsyslog, install logwatch for daily summaries. Bonus: Use HTTPS with Let's Encrypt, keep regular backups, scan for rootkits with rkhunter.

Model Answer: (1) Anonymous Pipes — simplest IPC, unidirectional, parent-child only. Use for: shell command chaining (ls | grep). (2) Named Pipes (FIFOs) — have file system presence, unrelated processes can connect. Use for: simple client-server communication on same machine (e.g., a daemon reading commands from a FIFO). (3) Shared Memory — fastest, processes directly access same memory region. Use for: high-performance data sharing (database buffer pools, video processing). Requires explicit synchronization (semaphores). (4) Message Queues — structured messages with types, kernel-managed ordering. Use for: multi-producer/consumer scenarios, when message prioritization is needed. Built-in synchronization. (5) Sockets — can work across networks (TCP/UDP). Use for: any inter-machine communication, web services, distributed systems. (6) Signals — asynchronous notifications. Use for: interrupt handling, process control (SIGTERM, SIGINT). Trade-off summary: Pipes = simple, Shared Memory = fast, Message Queues = structured, Sockets = networked.

Given: 4 processes with arrival time 0 and burst times: P1=6, P2=2, P3=8, P4=3

Find: Gantt chart, average waiting time, average turnaround time using FCFS.

Answer: Gantt: |P1(0-6)|P2(6-8)|P3(8-16)|P4(16-19)|
Waiting: P1=0, P2=6, P3=8, P4=16. Avg WT = (0+6+8+16)/4 = 7.5
Turnaround: P1=6, P2=8, P3=16, P4=19. Avg TAT = (6+8+16+19)/4 = 12.25

Given: Same processes: P1=6, P2=2, P3=8, P4=3 (all arrive at time 0)

Find: Gantt chart and average waiting time using SJF.

Answer: Order by burst: P2(2), P4(3), P1(6), P3(8). Gantt: |P2(0-2)|P4(2-5)|P1(5-11)|P3(11-19)|
Waiting: P2=0, P4=2, P1=5, P3=11. Avg WT = (0+2+5+11)/4 = 4.5
SJF is optimal for minimizing average waiting time.

Given: P1=6, P2=2, P3=8, P4=3 (all arrive at time 0). Quantum = 3.

Find: Gantt chart and average waiting time.

Answer: Gantt: |P1(0-3)|P2(3-5)|P3(5-8)|P4(8-11)|P1(11-14)|P3(14-17)|P3(17-19)|
Completion: P1=14, P2=5, P3=19, P4=11
Waiting: P1=14-6=8, P2=5-2=3, P3=19-8=11, P4=11-3=8. Avg WT = (8+3+11+8)/4 = 7.5

Given: P1(burst=10, priority=3), P2(burst=1, priority=1), P3(burst=2, priority=4), P4(burst=1, priority=5), P5(burst=5, priority=2). Lower number = higher priority. All arrive at time 0.

Find: Gantt chart and average waiting time.

Answer: Order: P2(pri=1), P5(pri=2), P1(pri=3), P3(pri=4), P4(pri=5). Gantt: |P2(0-1)|P5(1-6)|P1(6-16)|P3(16-18)|P4(18-19)|
Waiting: P2=0, P5=1, P1=6, P3=16, P4=18. Avg WT = (0+1+6+16+18)/5 = 8.2

Given: P1(AT=0, BT=7), P2(AT=2, BT=4), P3(AT=4, BT=1), P4(AT=5, BT=4)

Find: Gantt chart using Shortest Remaining Time First.

Answer: Gantt: |P1(0-2)|P2(2-4)|P3(4-5)|P2(5-7)|P4(7-11)|P1(11-16)|
At t=0: Only P1 (rem=7). At t=2: P2 arrives (rem=4 < 5). At t=4: P3 arrives (rem=1 < 2). At t=5: P2(rem=2) < P4(rem=4) < P1(rem=5).
Avg WT = (9+1+0+2)/4 = 3.0

Given: 3 processes, 3 resource types. Available = [3, 3, 2]

Find: Is the system in a safe state? If yes, find a safe sequence.

Answer: Available=[3,3,2]. P1 Need=[1,2,2]≤[3,3,2]→finish→Available=[5,3,2]. P0 Need=[7,4,3]→can't. P2 Need=[6,0,0]≤[5,3,2]→can't. No safe sequence with just P1. Try: P1→Available=[5,3,2], P2 Need=[6,0,0]→can't. System is NOT in safe state (P0 and P2 cannot complete).

Given: 5 processes, 3 resource types. Available = [3, 3, 2]

Answer: Available=[3,3,2]. P1[1,2,2]≤[3,3,2]✓→[5,3,2]. P3[0,1,1]≤[5,3,2]✓→[7,4,3]. P4[4,3,1]≤[7,4,3]✓→[7,4,5]. P0[7,4,3]≤[7,4,5]✓→[7,5,5]. P2[6,0,0]≤[7,5,5]✓→[10,5,7]. Safe sequence: P1→P3→P4→P0→P2

Given: Using the system from Problem 7 (safe state, Available=[3,3,2]). P1 requests [1,0,2].

Find: Can this request be granted?

Answer: Check: Request[1,0,2] ≤ Need_P1[1,2,2]? Yes. Request[1,0,2] ≤ Available[3,3,2]? Yes. Pretend to grant: Available=[2,3,0], Allocation_P1=[3,0,2], Need_P1=[0,2,0]. Run safety: P1[0,2,0]≤[2,3,0]✓→[5,3,2]. P3[0,1,1]≤[5,3,2]✓→[7,4,3]. P4→P0→P2 (same as before). Request CAN be granted.

Given: 3 processes, 1 resource type. Available=2. Allocation=[1,1,1], Max=[4,3,2]. Need=[3,2,1].

Find: Can P0 request 1 more unit?

Answer: Request=1 ≤ Need_P0=3? Yes. Request=1 ≤ Available=2? Yes. Pretend: Available=1, Alloc_P0=2, Need_P0=2. Safety: P2[Need=1≤1]✓→Avail=2. P1[Need=2≤2]✓→Avail=3. P0[Need=2≤3]✓→Avail=5. Safe! Request granted.

Given: 4 processes, 2 resource types. Available=[1,1]. Allocation=[[1,0],[0,1],[1,1],[0,0]]. Max=[[2,1],[1,2],[2,1],[1,1]]. Need=[[1,1],[1,1],[1,0],[1,1]].

Find: Safe sequence?

Answer: Available=[1,1]. P2[1,0]≤[1,1]✓→Avail=[2,2]. P0[1,1]≤[2,2]✓→Avail=[3,2]. P1[1,1]≤[3,2]✓→Avail=[3,3]. P3[1,1]≤[3,3]✓→Avail=[3,3]. Safe sequence: P2→P0→P1→P3

Given: Reference string: 7, 0, 1, 2, 0, 3, 0, 4, 2, 3. Frames = 3.

Find: Total page faults using FIFO.

Answer: [7]→F [7,0]→F [7,0,1]→F [2,0,1]→F(replace 7) [2,0,1]→H [2,3,1]→F(replace 0) [0,3,1]→F(replace 2) [0,4,1]→F(replace 3) [0,4,2]→F(replace 1) [3,4,2]→F(replace 0). Total page faults = 9

Given: Same reference string: 7, 0, 1, 2, 0, 3, 0, 4, 2, 3. Frames = 3.

Find: Total page faults using LRU.

Answer: [7]→F [7,0]→F [7,0,1]→F [2,0,1]→F(7 LRU) [2,0,1]→H [2,0,3]→F(1 LRU) [2,0,3]→H(0 is recent) Wait: [0,3]→need to replace LRU=2. [0,3,4]→F(2 LRU) [4,0,2]→F(3 LRU) [2,0,3]→F(4 LRU). Total page faults = 8

Given: Reference string: 7, 0, 1, 2, 0, 3, 0, 4, 2, 3. Frames = 3.

Find: Total page faults using Optimal.

Answer: [7]→F [7,0]→F [7,0,1]→F [2,0,1]→F(7 not used again) [2,0,1]→H [2,0,3]→F(1 used farthest) [2,0,3]→H [2,4,3]→F(0 used farthest? No, replace 0→[4,0,3]) Actually: replace 2 (used at pos 9 vs 0 at pos 7 vs 3 at pos 10). [0,3,4]→F [0,2,4]→F(3 used farthest) [0,2,3]→F(4 not used). Total page faults = 7 (minimum possible)

Given: Reference string: 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5.

Find: Page faults using FIFO with 3 frames and 4 frames.

Answer: With 3 frames: 1F 2F 3F 4F(→1) 1F(→2) 2F(→3) 5F(→4) 1H 2H 3F(→5) 4F(→1) 5F(→2) = 9 faults. With 4 frames: 1F 2F 3F 4F 1H 2H 5F(→1) 1F(→2) 2F(→3) 3F(→4) 4F(→5) 5F(→1) = 10 faults. More frames (4) → more faults (10 > 9). Belady's anomaly demonstrated!

Given: Reference string length = 20. Using LRU with 4 frames, there are 8 page faults.

Find: Page fault rate and hit rate.

Answer: Page fault rate = Faults / Total references = 8/20 = 0.4 or 40%. Hit rate = 1 - fault rate = 12/20 = 0.6 or 60%. If memory access time = 100ns and page fault service time = 10ms: Effective Access Time = (1-p)×100ns + p×10ms = 0.6×100 + 0.4×10,000,000 = 60 + 4,000,000 = 4,000,060 ns ≈ 4ms

Given: Disk requests: 98, 183, 37, 122, 14, 124, 65, 67. Head starts at track 53.

Find: Total head movement using FCFS.

Answer: 53→98(45) →183(85) →37(146) →122(85) →14(108) →124(110) →65(59) →67(2). Total = 45+85+146+85+108+110+59+2 = 640 tracks

Given: Same requests: 98, 183, 37, 122, 14, 124, 65, 67. Head at 53.

Find: Total head movement using SSTF.

Answer: 53→65(12) →67(2) →37(30) →14(23) →98(84) →122(24) →124(2) →183(59). Total = 12+2+30+23+84+24+2+59 = 236 tracks

Given: Same requests. Head at 53, moving toward 0. Disk range: 0–199.

Find: Total head movement using SCAN.

Answer: Moving left: 53→37(16) →14(23) →0(14). Reverse, moving right: 0→65(65) →67(2) →98(31) →122(24) →124(2) →183(59). Total = 16+23+14+65+2+31+24+2+59 = 236 tracks

Given: Same requests. Head at 53, moving toward 199. Disk range: 0–199.

Find: Total head movement using C-SCAN.

Answer: Moving right: 53→65(12) →67(2) →98(31) →122(24) →124(2) →183(59) →199(16). Jump to 0 (199). Moving right from 0: 0→14(14) →37(23). Total = 12+2+31+24+2+59+16+199+14+23 = 382 tracks

Given: From Problems 16–19, compare total head movements:

Conclusion: SSTF and SCAN performed best for this request set. However, SSTF can cause starvation of distant requests, while SCAN guarantees fairness. C-SCAN provides more uniform wait times despite higher total movement. FCFS is the simplest but has the worst performance.

☐ 1. CPU Scheduler Visualizer — Deployed on GitHub Pages with live URL. README with screenshots, algorithm comparison table, and usage instructions.

☐ 2. Banker's Algorithm Simulator — Working GUI (web or desktop). GitHub repo with clean README, safe/unsafe state detection, and request simulation.

☐ 3. Page Replacement Algorithm Comparator — Web-based tool comparing FIFO, LRU, Optimal. Shows step-by-step page table, hit/fault counters, comparison chart.

☐ 4. Linux Security Hardening Checklist — PDF document with 30+ items. Each item has: command, explanation, and risk rating. Formatted as a professional deliverable.

☐ 5. Shell Script Automation Bundle — 10 documented scripts on GitHub. Each script has usage examples, error handling, and comments. Includes a master README listing all scripts.

☐ 6. IPC Demo Repository — Working C programs for pipes, shared memory, message queues, and signals. Compiled and tested on Ubuntu. Makefile included.

☐ 7. LinkedIn Profile Complete — Professional photo, keyword-optimized headline and about section, all 6 projects linked, 15+ skills added, 50+ connections.

☐ 8. GitHub Profile Polished — Profile README, green contribution graph (commit daily!), pinned repos for top 3 projects, proper .gitignore and LICENSE on all repos.

☐ 9. Resume with OS Keywords — Naukri.com and LinkedIn resume updated with all keywords from Appendix D. Skills section matches job descriptions for target roles.

☐ 10. At Least 1 Freelance Gig Posted — Live gig on Fiverr, Upwork, or Internshala for Linux admin, shell scripting, or security audit services. Profile photo, portfolio samples, and pricing set.

Score: ___/10  |  Target: 10/10  |  Status: EARN-READY ✅

Unit 1: Introduction to Operating Systems → What is an OS? Types, structure, system calls

⬇️

Unit 2: Processes & Threads → Process lifecycle, PCB, threads, fork/exec

⬇️

Unit 3: CPU Scheduling → FCFS, SJF, Priority, Round Robin, Gantt charts

⬇️

Unit 4: Process Synchronization → Critical section, mutex, semaphore, producer-consumer

⬇️

Unit 5: Deadlocks → 4 conditions, Banker's algorithm, RAG, prevention/avoidance/detection

⬇️

Unit 6: Security & Protection → Access matrix, ACLs, buffer overflow, Linux security

⬇️

Unit 7: Memory Management → Paging, segmentation, virtual memory, page replacement

⬇️

Unit 8: File & Disk Management → File allocation, inodes, disk scheduling, RAID, journaling

⬇️

Unit 9: Inter-Process Communication → Pipes, shared memory, message queues, sockets, signals

⬇️

Unit 10: Integrated Capstone 🎯 → Portfolio, interview prep, career guidance, freelancing