অপারেটিং সিস্টেম কী আর কেন — কম্পিউটারের ব্যবস্থাপক

১ · কম্পিউটারের ব্যবস্থাপক — অপারেটিং সিস্টেম আসলে কী

একটি সাধারণ সকালের কথা ভাবুন। আপনার ফোনে একসাথে গান বাজছে, পেছনে WhatsApp নতুন বার্তা নামাচ্ছে, আর আপনি bKash অ্যাপ খুলে বিদ্যুৎ বিল দিচ্ছেন। ফোনে CPU core আছে হাতে গোনা কয়েকটি, মেমরিও সীমিত, স্পিকার একটি, পর্দা একটি। তবু তিনটি কাজ এমনভাবে চলছে যেন প্রত্যেকে পুরো ফোনটিই নিজের হাতে পেয়েছে। গান আটকে যাচ্ছে না, বার্তা হারাচ্ছে না, আর bKash-এর পিন অন্য অ্যাপ পড়তে পারছে না।

এই শৃঙ্খলা নিজে থেকে আসে না। পর্দার আড়ালে একটি সফটওয়্যার প্রতি মুহূর্তে সিদ্ধান্ত নিচ্ছে — এখন কে CPU পাবে, কে কতটুকু মেমরি পাবে, কোন বার্তা কোন অ্যাপের, কে কোন ফাইল পড়ার অনুমতি পায়। সেই সফটওয়্যারের নাম অপারেটিং সিস্টেম (Operating System, সংক্ষেপে OS). এই পর্ব পুরো কোর্সের দরজা — এখানে আমরা দেখব OS কী, কেন দরকার, আর ভেতরে মোটামুটি কীভাবে কাজ করে।

প্রথম দৃষ্টিভঙ্গি: OS একজন resource manager

কম্পিউটারের প্রতিটি সম্পদ (resource) সীমিত — CPU-র সময়, মেমরির জায়গা, ডিস্কের জায়গা, নেটওয়ার্কের গতি, প্রিন্টার। অনেক প্রোগ্রাম একসাথে এগুলো চায়। OS-এর প্রথম পরিচয় তাই একজন resource manager: সে সম্পদ ভাগ করে দেয়, কে কতটুকু পেল তার হিসাব রাখে, আর কাজ শেষে সম্পদ ফেরত নেয়।

ভাগ দুই রকমের হয়। সময়ে ভাগ (time multiplexing): একটি CPU পালা করে কয়েক মিলিসেকেন্ড এক প্রোগ্রামকে, কয়েক মিলিসেকেন্ড আরেকটিকে দেয় — এত দ্রুত যে মনে হয় সবাই একসাথে চলছে। জায়গায় ভাগ (space multiplexing): মেমরি বা ডিস্কের আলাদা আলাদা অংশ আলাদা প্রোগ্রামকে দেওয়া হয়। একসাথে অনেক প্রোগ্রাম চালানোর এই ক্ষমতার নাম multitasking.

দ্বিতীয় দৃষ্টিভঙ্গি: OS একটি extended machine

হার্ডওয়্যার নিজে খুব রুক্ষ। একটি SSD জানে শুধু “এই নম্বরের ব্লকে এই বাইটগুলো লেখো”; সে “ফাইল”, “ফোল্ডার” বা “resume.pdf” নামে কিছু চেনে না। নেটওয়ার্ক কার্ড জানে শুধু বাইটের প্যাকেট পাঠাতে। OS এই রুক্ষ হার্ডওয়্যারের ওপর একটি সুন্দর, সহজ “নকল যন্ত্র” দাঁড় করায় — একে বলে extended machine বা abstract machine. প্রোগ্রাম দেখে:

• ফাইল — নাম দেওয়া বাইটের সারি; ডিস্কের ব্লক, সেক্টর আর ফ্ল্যাশ চিপের ঝামেলা লুকানো।
• প্রসেস — চলমান একটি প্রোগ্রাম, যে ভাবে CPU যেন শুধু তার।
• নিজস্ব মেমরি — প্রতিটি প্রসেস ভাবে ঠিকানা 0 থেকে শুরু করে বিশাল একটি মেমরি শুধু তারই (পর্ব ৩৫-এ দেখবেন কীভাবে)।
• Socket — অন্য কম্পিউটারের সাথে কথা বলার একটি পাইপ, প্যাকেট আর তারের খুঁটিনাটি ছাড়া।

খেয়াল করুন, “অপারেটিং সিস্টেম” শব্দটি দুই অর্থে ব্যবহার হয়। সংকীর্ণ অর্থে OS মানে শুধু kernel — যে অংশ সবসময় মেমরিতে থাকে আর পূর্ণ ক্ষমতায় চলে। প্রশস্ত অর্থে OS মানে kernel-এর সাথে system library, background service, shell, ফাইল ম্যানেজার, এমনকি হোম স্ক্রিন — অর্থাৎ ফোন বা ল্যাপটপ কেনার সময় যা “Windows 11” বা “Android 15” নামে আসে। এই কোর্সে মূল মনোযোগ kernel-এর ওপর, কারণ আসল ব্যবস্থাপনা সেখানেই হয়।

২ · অ্যাপের আইকনে চাপ দিলে কী ঘটে

সংজ্ঞা মুখস্থ করার চেয়ে একটি বাস্তব ঘটনা অনুসরণ করা অনেক কাজের। আপনি ফোনের হোম স্ক্রিনে একটি অ্যাপের আইকনে আঙুল ছোঁয়ালেন — এক সেকেন্ডের কম সময়ে অ্যাপের পর্দা এলো। এর মধ্যে তিনটি স্তর অন্তত সাতবার হাত বদল করেছে। নিচের ডায়াগ্রামে “পরে” চাপুন; প্রতিটি ধাপে যে অংশগুলো কাজ করছে, সেগুলো লাল দাগে উজ্জ্বল হবে, আর নিচের টেবিলে দেখবেন CPU তখন কোন mode-এ।

সাত ধাপে একটি নিয়ম বারবার ফিরে এসেছে: অ্যাপ কখনো নিজে হার্ডওয়্যারে হাত দেয়নি। Touchscreen পড়েছে driver, মেমরি দিয়েছে memory manager, পর্দায় এঁকেছে GPU driver. অ্যাপ শুধু অনুরোধ করেছে। ল্যাপটপে কি-বোর্ডে চাপ দেওয়া, মাউসে ক্লিক বা Wi-Fi-তে একটি প্যাকেট আসা — সবকিছুই প্রায় একই পথে যায়: হার্ডওয়্যার → interrupt → driver → kernel → অ্যাপ.

৩ · OS-এর কাজের তালিকা — সাতটি বড় দায়িত্ব

রেস্তোরাঁর ম্যানেজারের যেমন কাজের একটি তালিকা থাকে — অর্ডার, চুলা, ভাঁড়ার, ক্যাশ, নিরাপত্তা — OS-এরও তেমনি কয়েকটি বড় দায়িত্ব আছে। এই কোর্সের প্রায় প্রতিটি মডিউল এর একটি দায়িত্ব নিয়ে।

এবার “resource manager” কথাটিকে চোখে দেখা যাক। ধরুন একটি ল্যাপটপে ৮ GB RAM আর একটিমাত্র CPU core (হিসাব সহজ রাখতে)। আপনি একে একে তিনটি প্রোগ্রাম খুললেন — গান শোনার প্লেয়ার, ওয়েব ব্রাউজার আর একটি বড় প্রজেক্ট compile করার compiler. প্রতিটি ধাপে OS কীভাবে মেমরি আর CPU-র সময় ভাগ করছে, দেখুন:

৪ · Kernel, shell, GUI আর সাধারণ প্রোগ্রাম — কে কোথায় থাকে

নতুনরা প্রায়ই গুলিয়ে ফেলেন — “Terminal-ই তো OS”, বা “Windows মানে ওই নীল-সাদা পর্দা আর Start বোতাম”. আসলে কয়েকটি আলাদা জিনিস একসাথে কাজ করে। একটি বড় অফিস ভবনের কথা ভাবুন।

সবচেয়ে গুরুত্বপূর্ণ কথা: shell আর GUI kernel-এর অংশ নয়। Linux-এ আপনি bash বদলে zsh বা fish বসাতে পারেন, GNOME বদলে KDE — kernel একই থাকে। Android আর একটি সাধারণ Linux সার্ভারের kernel একই পরিবারের, অথচ দেখতে সম্পূর্ণ আলাদা, কারণ ওপরের স্তরগুলো আলাদা।

User mode আর kernel mode — দুই রকম অনুমতি

অ্যাপ কেন নিজে হার্ডওয়্যারে হাত দিতে পারে না? কারণ CPU নিজেই এটি আটকায়। আধুনিক প্রায় সব CPU অন্তত দুটি অবস্থায় চলতে পারে। User mode-এ সাধারণ হিসাব-নিকাশ চলে, কিন্তু ডিভাইসে সরাসরি লেখা, অন্যের মেমরি ছোঁয়া বা interrupt বন্ধ করার মতো “বিশেষ নির্দেশ” (privileged instruction) চালানো নিষেধ — চেষ্টা করলে CPU নিজেই থেমে kernel-কে খবর দেয়। Kernel mode-এ সব নির্দেশ চলে; শুধু kernel-এর কোড এই অবস্থায় চলে।

এই ভাগের ফলেই একটি অ্যাপ crash করলে সাধারণত শুধু সেই অ্যাপটিই বন্ধ হয়, পুরো ফোন নয়। অনুরোধ করার নির্দিষ্ট দরজাটির নাম system call — যেমন “এই ফাইলটি খোলো”, “এই বাইটগুলো পর্দায় লেখো”, “আমাকে আরও মেমরি দাও”. প্রতিটি system call-এ CPU একটি বিশেষ নির্দেশে kernel mode-এ ঢোকে, কাজ শেষে আবার user mode-এ ফেরে। এর পুরো কারিগরি — কোন নির্দেশ, কোন register, কত খরচ — পর্ব ৫-এ।

ব্যাপারটা নিজে মেপে দেখা যায়। প্রতিটি প্রসেসের CPU-সময় OS দুই ভাগে হিসাব রাখে: user (নিজের কোডে কাটানো সময়) আর sys (তার হয়ে kernel-এর খাটুনি)। নিচের bash স্ক্রিপ্ট দুটি কাজ মাপে — প্রথমটি শুধু যোগ-বিয়োগ, দ্বিতীয়টি এক বাইট করে পড়ে-লেখে, অর্থাৎ বিপুল সংখ্যক system call করে। চালিয়ে দেখুন:

TIMEFORMAT='   real %R s | user %U s | sys %S s'

echo "1) pure arithmetic in bash (no system calls in the loop):"
{ time { s=0; for ((i=0; i<200000; i++)); do s=$((s+i)); done; }; } 2>&1
echo "   sum = $s"

echo "2) dd copies 200000 bytes, ONE byte per read()/write():"
{ time dd if=/dev/zero of=/dev/null bs=1 count=200000 status=none; } 2>&1

echo "3) same 200000 bytes in ONE big read()/write():"
{ time dd if=/dev/zero of=/dev/null bs=200000 count=1 status=none; } 2>&1

1) pure arithmetic in bash (no system calls in the loop):
   real 0.848 s | user 0.848 s | sys 0.000 s
   sum = 19999900000
2) dd copies 200000 bytes, ONE byte per read()/write():
   real 0.325 s | user 0.071 s | sys 0.252 s
3) same 200000 bytes in ONE big read()/write():
   real 0.003 s | user 0.000 s | sys 0.002 s

৫ · Interrupt — একটি কি-চাপ কীভাবে CPU পর্যন্ত পৌঁছায়

OS তো একটি প্রোগ্রাম; CPU যখন আপনার ভিডিও প্লেয়ার চালাচ্ছে, তখন kernel আসলে চলছে না। তাহলে আপনি কি-বোর্ডে চাপ দিলে kernel টের পায় কীভাবে? CPU কি প্রতি মুহূর্তে কি-বোর্ডকে জিজ্ঞেস করে “কিছু চাপা হলো?” — এভাবে বারবার জিজ্ঞেস করাকে বলে polling, আর এতে CPU-র সময় নষ্ট হয়। প্রধান সমাধান হলো interrupt: ডিভাইস নিজেই CPU-কে একটি সংকেত দিয়ে থামায়।

Interrupt-ই OS-এর হৃদস্পন্দন। কি-বোর্ড, নেটওয়ার্ক কার্ড, ডিস্ক — সবাই interrupt পাঠায়। সবচেয়ে গুরুত্বপূর্ণটি আসে একটি timer থেকে: OS নিয়মিত বিরতিতে timer interrupt-এর ব্যবস্থা করে রাখে, তাই কোনো প্রোগ্রাম CPU আঁকড়ে থাকতে চাইলেও (যেমন অসীম লুপে আটকে) kernel নিয়ম করে নিয়ন্ত্রণ ফিরে পায় আর অন্যকে পালা দিতে পারে। Interrupt, timer আর DMA-র হার্ডওয়্যার-দিক পর্ব ৪-এ, আর ডিভাইসের দিক পর্ব ৩৯-এ।

৬ · হাতে-কলমে: চলমান OS-কে প্রশ্ন করুন

এতক্ষণ ধারণা। এবার একটি আসল চলমান Linux-কে প্রশ্ন করি। নিচের কোড চলবে একটি দূরের সার্ভারের container-এ (একটি আলাদা করা ছোট পরিবেশ — পর্ব ৫১-এ এর ভেতরটা দেখবেন)। তাই আপনার নিজের ফোন বা ল্যাপটপের নয়, সেই সার্ভারের তথ্য আসবে।

echo "== kernel name and release =="
uname -sr

echo "== CPU cores this process may use =="
nproc

echo "== memory, as the kernel reports it =="
head -n 3 /proc/meminfo

echo "== a few running processes =="
ps -e -o pid,ppid,comm | head -n 6
echo "processes visible here: $(ps -e --no-headers | wc -l)"

echo "== this shell itself =="
echo "my pid = $$, my parent's pid = $PPID"

== kernel name and release ==
Linux 6.8.0-137-generic
== CPU cores this process may use ==
2
== memory, as the kernel reports it ==
MemTotal:        2008912 kB
MemFree:          189652 kB
MemAvailable:    1345164 kB
== a few running processes ==
    PID    PPID COMMAND
      1       0 podman-init
      2       1 bash
      6       2 ps
      7       2 head
processes visible here: 5
== this shell itself ==
my pid = 2, my parent's pid = 1

এবার একই প্রশ্ন C ভাষা থেকে — যে ভাষায় Linux, Windows আর macOS-এর kernel-এর বড় অংশ লেখা। getpid() একটি আসল system call; sysconf() glibc-এর ফাংশন, যা kernel-এর দেওয়া তথ্য থেকে উত্তর বানায়। ঠিক কোন সংখ্যা আসবে তা মেশিনভেদে বদলায়, তাই প্রোগ্রামটি সংখ্যার বদলে সম্পর্ক ছাপে:

#include <stdio.h>
#include <unistd.h>

int main(void) {
    pid_t me     = getpid();                 /* system call: who am I?  */
    pid_t parent = getppid();                /* who started me?         */
    long page    = sysconf(_SC_PAGESIZE);    /* memory is handed out in pages */
    long cpus    = sysconf(_SC_NPROCESSORS_ONLN);
    long pages   = sysconf(_SC_PHYS_PAGES);

    printf("my pid > 0 ............. %s\n", me > 0 ? "yes" : "no");
    printf("parent pid != my pid ... %s\n", parent != me ? "yes" : "no");
    printf("page size (bytes) ...... %ld\n", page);
    printf("page size power of 2 ... %s\n", (page & (page - 1)) == 0 ? "yes" : "no");
    printf("online CPUs >= 1 ....... %s\n", cpus >= 1 ? "yes" : "no");
    printf("RAM >= 256 MB .......... %s\n",
           pages * page >= 256L * 1024 * 1024 ? "yes" : "no");

    /* write() is the system call that printf itself uses underneath */
    const char msg[] = "this line came from write(), not printf\n";
    fflush(stdout);                 /* empty printf's buffer first */
    if (write(1, msg, sizeof msg - 1) < 0)
        return 1;
    return 0;
}

my pid > 0 ............. yes
parent pid != my pid ... yes
page size (bytes) ...... 4096
page size power of 2 ... yes
online CPUs >= 1 ....... yes
RAM >= 256 MB .......... yes
this line came from write(), not printf

এই প্রোগ্রাম Linux আর macOS-এ চলবে (দুটোই POSIX মান মেনে চলে), কিন্তু Windows-এর সাধারণ compiler-এ unistd.h নেই — Windows-এর নিজস্ব API (Win32) আলাদা: GetCurrentProcessId(), GetSystemInfo(). অন্য OS-এ একই তথ্য দেখার কমান্ড:

Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version
(Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors
Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 5 Name, Id

sw_vers                 # macOS-এর version
uname -sr               # kernel: Darwin (XNU)
sysctl -n hw.ncpu       # CPU core
ps -e -o pid,ppid,comm | head -n 6

cat /etc/os-release | head -n 2   # distribution-এর নাম
uname -sr                         # kernel version
free -h                           # RAM আর swap, মানুষের পড়ার মতো এককে

৭ · যে অপারেটিং সিস্টেমগুলোর সাথে আপনার দেখা হয়

পৃথিবীতে অসংখ্য OS আছে, কিন্তু দৈনন্দিন জীবনে আপনি মূলত কয়েকটি পরিবারের দেখা পান। নিচের টেবিলে বাজারের অংশ নিয়ে কোনো নির্দিষ্ট শতাংশ দেওয়া হয়নি, কারণ জরিপভেদে আর বছরভেদে সংখ্যা বদলায়; শুধু সাধারণভাবে স্বীকৃত প্রবণতা লেখা হলো।

শেষ সারিটি আলাদা মনোযোগ দাবি করে। একটি RTOS (real-time operating system)-এর মূল প্রতিশ্রুতি “দ্রুত” নয়, “সময়মতো”. গাড়ির airbag-এর কন্ট্রোলার যদি বেশিরভাগ সময় ১ মিলিসেকেন্ডে সাড়া দেয় কিন্তু কখনো কখনো ২০০ মিলিসেকেন্ড নেয়, সেটি অচল। RTOS এমনভাবে নকশা করা যে সবচেয়ে খারাপ অবস্থাতেও সাড়া দেওয়ার একটি নির্দিষ্ট সীমা মানা হয়। এমন যন্ত্রকে বলে embedded system — যেখানে কম্পিউটারটি একটি বড় যন্ত্রের ভেতরে লুকানো। পর্ব ২০ আর ৫৪-এ এ নিয়ে বিস্তারিত।

৮ · AI-এর যুগে OS জানা কেন আরও জরুরি

“AI তো কোড লিখে দেয়, সার্ভারও নিজেই বানিয়ে দেয় — OS শিখে কী হবে?” প্রশ্নটি যৌক্তিক। কিন্তু AI-এর লেখা কোড শেষ পর্যন্ত চলে একটি OS-এর ওপর, আর সমস্যা হলে লক্ষণগুলো আসে OS-এর ভাষায়: Killed, Too many open files, Permission denied, Segmentation fault, CPU ১০০%, ডিস্ক ভরে যাওয়া। চারটি জায়গায় OS-জ্ঞান সরাসরি কাজে লাগে:

• পারফরম্যান্স: প্রোগ্রাম ধীর কেন — CPU-র কাজ বেশি (user সময়), নাকি system call-এর ভিড় (sys), নাকি ডিস্ক বা নেটওয়ার্কের অপেক্ষা, নাকি RAM কম পড়ে swap হচ্ছে? উপরের ছোট পরীক্ষাতেই দেখলেন, এক বাইট করে পড়া কত ব্যয়বহুল। AI মডেল চালানোর সার্ভারেও GPU, মেমরি আর ডেটা লোডিংয়ের ভারসাম্য OS-এর বিষয়। (পর্ব ৫৭)
• Debugging: Segmentation fault মানে kernel আপনার প্রসেসকে নিষিদ্ধ মেমরিতে হাত দেওয়ার জন্য থামিয়েছে; Killed লেখা দেখলে প্রায়ই মেমরি ফুরিয়ে OOM killer কাজ করেছে। লক্ষণ চিনলে আধা কাজ শেষ। (পর্ব ১৩, ৩৮)
• Container আর cloud: Docker container কোনো জাদু নয় — Linux kernel-এর namespace আর cgroup সুবিধা দিয়ে একটি প্রসেসকে আলাদা করে রাখা। তাই container-এর ভেতরে nproc বা মেমরির সীমা বাইরের থেকে আলাদা হতে পারে, যা উপরের পরীক্ষায় দেখলেন। (পর্ব ৫০–৫২)
• নিরাপত্তা: কোন প্রোগ্রাম কোন ফাইল পড়তে পারে, কেন chmod 777 বিপজ্জনক, কেন সব কিছু sudo দিয়ে চালানো ঠিক নয় — এগুলো OS-এর protection ব্যবস্থা বোঝার প্রশ্ন। (মডিউল ৭)

OS-এর প্রশ্নে AI সাধারণত যেসব ভুল করে

AI-এর দেওয়া সিস্টেম-কমান্ড চালানোর আগে — চেকলিস্ট

• কমান্ডটি আমার OS, distribution আর shell-এর জন্যই — Windows-এ bash কমান্ড বা উল্টোটা নয়
• প্রতিটি অংশ কী করে man পাতা বা --help দেখে বুঝেছি; কিছু মুছে ফেলে বা বদলায় এমন কমান্ড আগে পরীক্ষার পরিবেশে চালিয়েছি
• sudo, chmod 777, rm -rf বা নিরাপত্তা বন্ধ করার পরামর্শ এলে থেমে কারণ জিজ্ঞেস করেছি
• kernel বা টুলের version-নির্ভর দাবি নিজের uname -r আর অফিসিয়াল ডকুমেন্টেশনের সাথে মিলিয়েছি
• সংখ্যা-হিসাব (scheduling, page replacement, disk) অন্তত একবার হাতে করে মিলিয়েছি
• concurrent কোড একবার নয়, বহুবার আর ভারী ভারে চালিয়ে দেখেছি

৯ · সামনের পথ — ৬৪ পর্ব, ১০টি মডিউল

এই কোর্স সাজানো হয়েছে ঠিক এই পর্বের কাজের তালিকা ধরে। শুরু হবে ভিত্তি দিয়ে, তারপর OS-এর প্রতিটি বড় দায়িত্ব আলাদা মডিউলে, আর শেষে বাস্তব OS আর পরীক্ষা-ইন্টারভিউর প্রস্তুতি।

কীভাবে পড়বেন? একেবারে নতুন হলে ক্রম ধরে এগোন, প্রতিটি পর্বের ডায়াগ্রামগুলো নিজে চালিয়ে দেখুন — তত্ত্বের অংশ প্রথমবার পুরো না বুঝলেও ক্ষতি নেই। বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষার প্রস্তুতি নিলে মডিউল ৩, ৪, ৫-এর numerical আর প্রমাণগুলো খাতায় হাতে করুন, আর মডিউল ১০ দিয়ে যাচাই করুন। পেশাদার ডেভেলপার বা DevOps প্রকৌশলী হলে “আরও গভীরে” বাক্সগুলো আর মডিউল ৮–৯ আপনার জন্য বিশেষভাবে কাজের।