OS-এর ইতিহাস আর ধরন — batch থেকে মোবাইল আর ক্লাউড

১ · OS ছাড়া কম্পিউটার — হাতে চালানো থেকে batch

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

প্রথম প্রজন্ম: OS নেই, সব হাতে (১৯৪০ ও ১৯৫০-এর দশকের শুরু)

১৯৪০-এর দশকের কম্পিউটার (যেমন ENIAC) ছিল ঘরভর্তি vacuum tube. প্রোগ্রামার নিজেই অপারেটর। তিনি একটি খাতায় নাম লিখে যন্ত্রের সময় “বুক” করতেন — ধরুন রাত ২টা থেকে ৩টা। নির্ধারিত সময়ে এসে সুইচ, প্লাগবোর্ড বা পরে punch card দিয়ে প্রোগ্রাম ঢোকাতেন, চালাতেন, ফল প্রিন্ট করে নিয়ে যেতেন। একে বলে serial processing — একজনের পর একজন, হাতে হাতে।

এতে দুটি বড় অপচয় ছিল। প্রথমত, setup time: compiler-এর টেপ লাগানো, কার্ড সাজানো, প্রিন্টার তৈরি করা — এই সময়ে যন্ত্র কিছুই গণনা করছে না। দ্বিতীয়ত, বুকিংয়ের অপচয়: ৪৫ মিনিটে কাজ শেষ হলে বাকি ১৫ মিনিট যন্ত্র ফাঁকা; আর কাজ শেষ না হলে মাঝপথে উঠে যেতে হতো। যন্ত্রটির দাম তখন লক্ষ লক্ষ ডলার, তাই প্রতিটি অলস মিনিটই ছিল বিশাল ক্ষতি।

দ্বিতীয় প্রজন্ম: batch system আর resident monitor (১৯৫০-এর দশকের মাঝামাঝি থেকে)

সমাধান এলো: প্রোগ্রামাররা আর যন্ত্রের সামনে যাবেন না। তাঁরা punch card-এ কাজ (job) জমা দেবেন একজন পেশাদার অপারেটরের কাছে। অপারেটর একই ধরনের কাজগুলো (যেমন সব FORTRAN কাজ) একসাথে সাজিয়ে একটি “batch” বানাবেন, যাতে compiler একবার লোড করেই অনেক কাজ চালানো যায়। এটিই batch system.

কিন্তু এক কাজ শেষে পরেরটি শুরু করবে কে? এর জন্য মেমরিতে সবসময় একটি ছোট প্রোগ্রাম বসে থাকত — resident monitor. এটিকেই আধুনিক OS-এর পূর্বপুরুষ বলা যায়। Monitor কার্ড পড়ত, প্রতিটি কাজের শুরুর বিশেষ নির্দেশ-কার্ড দেখে বুঝত কোন compiler লাগবে, কাজটি চালাত, শেষ হলে নিয়ন্ত্রণ ফিরে পেয়ে পরের কাজে যেত। এই নির্দেশগুলোর ভাষাকে বলা হতো job control language (JCL) — IBM-এর বড় যন্ত্রগুলোর JCL আজও কিছু ব্যাংক আর বিমা প্রতিষ্ঠানের mainframe-এ চলে।

Batch-যুগে আরও একটি কৌশল আসে: ধীর card reader আর printer যাতে দ্রুত CPU-কে আটকে না রাখে, তাই একটি ছোট, সস্তা কম্পিউটার আগেই কার্ড থেকে ম্যাগনেটিক টেপে কাজগুলো কপি করে রাখত (offline I/O). পরে ডিস্ক আসার পর এর উন্নত রূপ হলো spooling (Simultaneous Peripheral Operation On-Line) — ইনপুট আগেই ডিস্কে জমা, আউটপুট ডিস্কে লিখে পরে ধীরে ধীরে প্রিন্ট। আজও আপনার কম্পিউটারে “print spooler” সার্ভিসটি ঠিক এই কাজ করে।

Batch-এর ধারণা আজও মরে যায়নি। ব্যাংকের দিনশেষের হিসাব মেলানো (end-of-day processing), মাসশেষে বেতনের হিসাব, গবেষণাগারের supercomputer-এ জমা দেওয়া simulation কাজ (Slurm-এর মতো job scheduler), কিংবা Linux-এর cron দিয়ে রাতে চালানো backup — সবই batch-চিন্তা: মানুষ পাশে না বসেও কাজ সারির পর সারি চলে।

২ · Multiprogramming — CPU-কে অলস বসে থাকতে না দেওয়া

Batch অপারেটরের সময় বাঁচাল, কিন্তু একটি কাজ চলার ভেতরেও অপচয় রয়ে গেল। একটি সাধারণ কাজ কিছুক্ষণ হিসাব করে (CPU burst), তারপর টেপ বা ডিস্ক থেকে ডেটা পড়ে (I/O burst), আবার হিসাব করে। I/O যন্ত্র CPU-র চেয়ে হাজার গুণ ধীর। মেমরিতে যদি একটিমাত্র কাজ থাকে (uniprogramming), তাহলে প্রতিবার I/O-র সময় CPU চুপচাপ বসে থাকে।

সমাধান: মেমরিকে কয়েক ভাগে ভাগ করে একসাথে কয়েকটি কাজ রাখা। একটি কাজ I/O-র জন্য অপেক্ষা শুরু করলেই OS CPU-টি আরেকটি প্রস্তুত (ready) কাজকে দিয়ে দেবে। এটাই multiprogramming. এর লক্ষ্য একটাই — CPU utilisation (CPU কত শতাংশ সময় কাজে ব্যস্ত) বাড়ানো।

নিচের ডায়াগ্রামে একই তিনটি কাজ (J1, J2, J3) দুইভাবে চালানো হয়েছে। প্রতিটি কাজ CPU → I/O → CPU — এই তিন ভাগে। সময়ের একক ধরুন মিলিসেকেন্ড। ধরে নেওয়া হয়েছে প্রতিটি কাজের I/O আলাদা যন্ত্রে হয়, তাই একাধিক I/O একসাথে চলতে পারে।

হাতে হিসাব করা ভালো, কিন্তু কাজ বাড়লে হাতে আর কুলায় না। নিচের ছোট simulator একই তিনটি কাজের হিসাব নিজে করে। jobs তালিকার সংখ্যা বদলে নিজের কাজের মিশ্রণ দিয়ে চালিয়ে দেখুন:

// each job: alternating CPU and I/O bursts (time units), starting and ending with CPU
const jobs = [
  { name: "J1", bursts: [2, 3, 1] },
  { name: "J2", bursts: [1, 4, 2] },
  { name: "J3", bursts: [2, 2, 2] },
];
function uni(jobs) {               // one job in memory at a time
  let t = 0, busy = 0, line = "";
  for (const j of jobs)
    j.bursts.forEach((b, k) => {
      t += b; if (k % 2 === 0) busy += b;
      line += (k % 2 === 0 ? j.name[1] : ".").repeat(b);
    });
  return { t, busy, line };
}
function multi(jobs) {             // all jobs in memory, FCFS ready queue
  const st = jobs.map(j => ({ ...j, k: 0, readyAt: 0 }));
  let t = 0, busy = 0, line = "", done = 0;
  while (done < st.length) {
    const ready = st.filter(j => j.k < j.bursts.length && j.readyAt <= t)
                    .sort((a, b) => a.readyAt - b.readyAt);
    if (!ready.length) { t++; line += "."; continue; }   // CPU idle
    const j = ready[0], b = j.bursts[j.k];
    t += b; busy += b; line += j.name[1].repeat(b);
    if (++j.k < j.bursts.length) { j.readyAt = t + j.bursts[j.k]; j.k++; }
    else done++;
  }
  return { t, busy, line };
}

for (const [label, r] of [["Uniprogramming  ", uni(jobs)], ["Multiprogramming", multi(jobs)]]) {
  console.log(label, "CPU:", r.line);
  console.log("   total time =", r.t, " CPU busy =", r.busy,
              " utilisation =", (100 * r.busy / r.t).toFixed(1) + "%");
}

Uniprogramming   CPU: 11...12....2233..33
   total time = 19  CPU busy = 10  utilisation = 52.6%
Multiprogramming CPU: 112331.2233
   total time = 11  CPU busy = 10  utilisation = 90.9%

কতগুলো কাজ মেমরিতে রাখলে CPU কতটা ব্যস্ত থাকে — 1 − pⁿ

একটি সহজ সম্ভাবনার মডেল দিয়ে multiprogramming-এর লাভ মাপা যায়। ধরুন প্রতিটি কাজ তার সময়ের p অংশ I/O-র অপেক্ষায় কাটায় (p = 0.8 মানে ৮০% সময় অপেক্ষা)। মেমরিতে একসাথে n-টি কাজ আছে — একে বলে degree of multiprogramming. CPU অলস থাকে কেবল তখনই, যখন সব কাজ একসাথে অপেক্ষায়। কাজগুলো একে অপরের থেকে স্বাধীন ধরলে সেই সম্ভাবনা p × p × … × p = pⁿ. তাই:

সমাধান করা উদাহরণ। একটি সার্ভারে RAM 8 GB; OS নিজে রাখে 2 GB, আর প্রতিটি কাজের লাগে 1.5 GB. প্রতিটি কাজ ৮০% সময় I/O-র অপেক্ষায় (p = 0.8).

• কয়টি কাজ ধরবে? (8 − 2) ÷ 1.5 = 4টি। CPU ব্যবহার = 1 − 0.8⁴ = 1 − 0.4096 = 0.5904 ≈ ৫৯.০%.
• আরও 6 GB RAM কিনলে (মোট 14 GB): (14 − 2) ÷ 1.5 = 8টি কাজ। 0.8⁸ ≈ 0.1678, তাই ব্যবহার ≈ ৮৩.২% — লাভ প্রায় ২৪ শতাংশ-বিন্দু।
• আরও 6 GB (মোট 20 GB): 12টি কাজ। 0.8¹² ≈ 0.0687, ব্যবহার ≈ ৯৩.১% — এবার লাভ মাত্র প্রায় ১০ শতাংশ-বিন্দু।

একই পরিমাণ RAM দ্বিতীয়বার কিনে লাভ অর্ধেকেরও কম। একে বলে diminishing returns (ক্রমহ্রাসমান লাভ) — pⁿ যত ছোট হয়, ১ থেকে তার দূরত্ব কমানো তত কঠিন। নিচের কোড পুরো টেবিলটি তৈরি করে:

// CPU utilisation = 1 - p^n  (p = fraction of time a job waits for I/O)
const util = (p, n) => 100 * (1 - Math.pow(p, n));

console.log(" n   p=0.2    p=0.5    p=0.8");
for (const n of [1, 2, 3, 4, 6, 8, 10]) {
  const row = [0.2, 0.5, 0.8].map(p => util(p, n).toFixed(1).padStart(6) + "%");
  console.log(String(n).padStart(2), row.join("  "));
}

// RAM example: OS keeps 2 GB, each job needs 1.5 GB, p = 0.8
for (const ram of [8, 14, 20]) {
  const n = Math.floor((ram - 2) / 1.5);
  console.log(`RAM ${ram} GB -> ${n} jobs -> CPU ${util(0.8, n).toFixed(1)}%`);
}

 n   p=0.2    p=0.5    p=0.8
 1   80.0%    50.0%    20.0%
 2   96.0%    75.0%    36.0%
 3   99.2%    87.5%    48.8%
 4   99.8%    93.8%    59.0%
 6  100.0%    98.4%    73.8%
 8  100.0%    99.6%    83.2%
10  100.0%    99.9%    89.3%
RAM 8 GB -> 4 jobs -> CPU 59.0%
RAM 14 GB -> 8 jobs -> CPU 83.2%
RAM 20 GB -> 12 jobs -> CPU 93.1%

Multiprogramming চালু করতে OS-কে হঠাৎ অনেক নতুন দায়িত্ব নিতে হলো: কোন কাজ মেমরির কোথায় থাকবে (memory management — মডিউল ৫), কে পরে CPU পাবে (CPU scheduling — মডিউল ৩), আর এক কাজ যেন অন্যের মেমরিতে হাত না দেয় (protection — মডিউল ৭)। মানচেস্টারের Atlas কম্পিউটার (১৯৬০-এর দশকের শুরু) আর IBM-এর OS/360 (১৯৬০-এর দশকের মাঝামাঝি) এই ধারণাকে বড় আকারে বাস্তবে আনে। আজকের OS-এর প্রায় সব মূল সমস্যার জন্ম এখানেই।

৩ · Time-sharing — অনেক মানুষ, একটি কম্পিউটার

Multiprogramming যন্ত্রকে ব্যস্ত রাখল, কিন্তু মানুষকে নয়। প্রোগ্রামার তখনো কার্ড জমা দিয়ে ঘণ্টার পর ঘণ্টা অপেক্ষা করেন। ১৯৬০-এর দশকের শুরুতে একটি নতুন প্রশ্ন উঠল: যদি অনেক মানুষ একসাথে আলাদা আলাদা terminal (কীবোর্ড আর স্ক্রিন/টেলিপ্রিন্টার) থেকে একটি কম্পিউটারের সাথে সরাসরি “কথা” বলতে পারেন?

উত্তর time-sharing: CPU-র সময়কে ছোট ছোট টুকরোয় (time quantum, পাঠ্যবইয়ের উদাহরণে সাধারণত কয়েক থেকে কয়েক ডজন মিলিসেকেন্ড) ভাগ করে প্রত্যেক ব্যবহারকারীকে পালা করে দেওয়া। পালা এত দ্রুত ঘোরে যে প্রত্যেকের মনে হয় যন্ত্রটি শুধু তাঁরই। এখানে চাবিকাঠি হলো একটি হার্ডওয়্যার timer interrupt: নির্দিষ্ট সময় পরপর ঘড়িটি CPU-কে থামিয়ে OS-কে ডাকে, আর OS চলতি কাজকে সরিয়ে (preemption) পরের জনকে CPU দেয়। কাজ বদলের এই প্রক্রিয়াই context switch — এর খুঁটিনাটি পর্ব ০৯-এ।

নিচের ডায়াগ্রামে তিনজন ব্যবহারকারী — রিনা (A, তার কাজে CPU লাগবে মোট 5 ms), সাকিব (B, 3 ms) আর তানিয়া (C, 4 ms) — একসাথে কমান্ড দিলেন। Quantum 2 ms, পালা চলে গোল হয়ে (round robin). Context switch-এর খরচ এখানে শূন্য ধরা হয়েছে।

৪ · চারটি “multi”-র জট — নিখুঁত সংজ্ঞা

বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষায় সবচেয়ে বেশি গুলিয়ে ফেলা প্রশ্নগুলোর একটি: multiprogramming, multitasking, multiprocessing আর multithreading-এর পার্থক্য কী? শব্দগুলো কাছাকাছি, কিন্তু প্রত্যেকে একেবারে আলাদা প্রশ্নের উত্তর দেয়। প্রথমে দুটি ভিত্তি-শব্দ: process হলো চলমান একটি প্রোগ্রাম, নিজের মেমরিসহ (পর্ব ০৮); আর thread হলো একটি প্রসেসের ভেতরের একটি স্বাধীন নির্বাহ-ধারা (execution path), যা প্রসেসের মেমরি অন্য thread-এর সাথে ভাগ করে (পর্ব ১৪)।

এদের সম্পর্কটি বোঝার সবচেয়ে ভালো উপায় — এগুলো পরস্পর-বিরোধী নয়, আলাদা অক্ষের মাপ। আজকের একটি ল্যাপটপ চারটিই একসাথে করে: মেমরিতে শতাধিক প্রসেস (multiprogramming), timer দিয়ে পালা বদল (multitasking), ৮টি core (multiprocessing), আর ব্রাউজারের ভেতরে ডজন ডজন thread (multithreading). আবার ১৯৯০-এর দশকের একক-core কম্পিউটারেও multithreading সম্ভব ছিল — thread-গুলো পালা করে চলত, একসাথে নয়।

Cooperative বনাম preemptive multitasking

Multitasking দুই রকম। Cooperative-এ প্রতিটি প্রোগ্রাম নিজে থেকে মাঝে মাঝে CPU ছেড়ে দেয় — একটি প্রোগ্রাম আটকে গেলে (অসীম লুপে পড়লে) পুরো কম্পিউটার জমে যায়। Windows 3.x আর পুরোনো Mac OS (Mac OS 9 পর্যন্ত) মূলত এভাবে চলত। Preemptive-এ OS timer interrupt দিয়ে জোর করে CPU কেড়ে নেয়; কোনো প্রোগ্রাম চাইলেও CPU আটকে রাখতে পারে না। Unix প্রথম থেকেই preemptive ছিল; Windows-এ ৩২-বিট প্রোগ্রামের জন্য তা আসে Windows 95 আর NT-তে, Mac-এ আসে Mac OS X-এ। আজকের সব সাধারণ OS preemptive.

Multiprocessing-এর দুই নকশা

Symmetric multiprocessing (SMP)-এ সব CPU সমান — যেকোনো CPU OS-এর কোড আর যেকোনো প্রসেস চালাতে পারে, সবাই একই মেমরি দেখে। আজকের ল্যাপটপ আর সার্ভার এই নকশার। Asymmetric (AMP)-এ একটি প্রধান CPU কাজ বণ্টন করে, বাকিরা নির্দিষ্ট দায়িত্ব পালন করে — পুরোনো কিছু বড় যন্ত্রে আর এখনকার অনেক embedded চিপে (যেমন একটি core OS চালায়, আরেকটি শুধু রেডিও সামলায়) দেখা যায়। ফোনের big.LITTLE ধরনের চিপে core-গুলোর ক্ষমতা আলাদা হলেও সবাই একই OS চালায় — একে heterogeneous multiprocessing বলা হয়। একাধিক CPU থাকলে কোন প্রসেস কোন core-এ চলবে, সেই প্রশ্ন পর্ব ২০-এ।

৫ · ব্যক্তিগত কম্পিউটার, নেটওয়ার্ক আর distributed OS

১৯৭০-এর দশকে microprocessor আসার পর কম্পিউটার ঘর থেকে নেমে এলো টেবিলে। Altair 8800 (১৯৭৫), Apple II (১৯৭৭), IBM PC (১৯৮১) — এক মানুষ, এক যন্ত্র। মজার ব্যাপার, প্রথম দিকের PC OS-গুলো (CP/M, MS-DOS) ছিল আবার uniprogramming আর প্রায় সুরক্ষাহীন — এক ব্যবহারকারী, একটি প্রোগ্রাম, মেমরি-সুরক্ষা নেই। কারণ লক্ষ্য বদলে গিয়েছিল: যন্ত্র এখন সস্তা, মানুষের সময় দামি। তাই অগ্রাধিকার পেল সহজ ব্যবহার — Xerox PARC-এর Alto-তে (১৯৭৩) জন্ম নেওয়া graphical user interface (GUI), যা জনপ্রিয় করে Apple Macintosh (১৯৮৪) আর পরে Windows.

যন্ত্র যখন শক্তিশালী হলো আর ইন্টারনেটে যুক্ত হলো, তখন বড় যন্ত্রের পুরোনো সমস্যাগুলো — একাধিক প্রোগ্রাম, সুরক্ষা, ভাইরাস — আবার ফিরে এলো। তাই আজকের PC OS ভেতরে আসলে ১৯৬০-৭০-এর time-sharing OS-এর বংশধর। ইতিহাস এখানে একটি বৃত্ত: প্রতিটি নতুন ধরনের যন্ত্র (mainframe → minicomputer → PC → ফোন → ঘড়ি) প্রথমে সরল OS দিয়ে শুরু হয়, তারপর ধীরে ধীরে বড় যন্ত্রের সব ধারণা আবার শেখে।

Network OS বনাম distributed OS

একাধিক কম্পিউটার নেটওয়ার্কে জুড়লে দুই ধরনের নকশা সম্ভব, আর পরীক্ষায় দুটির পার্থক্য প্রায়ই চাওয়া হয়:

একটি distributed system-এ বিশুদ্ধ distributed OS বাস্তবে খুব কমই সফল হয়েছে। তার বদলে আজকের দুনিয়া চলে মাঝামাঝি পথে: প্রতিটি যন্ত্রে সাধারণ OS (প্রায় সবসময় Linux), আর তার ওপরে একটি স্তর — Kubernetes, Hadoop, distributed database — যা অনেক যন্ত্রকে একসাথে পরিচালনা করে। এই স্তরগুলোকে কখনো কখনো “ডেটা সেন্টারের OS” বলা হয়। বড় ই-কমার্স সাইট বা মোবাইল ব্যাংকিং সেবার পেছনে ঠিক এমন শত শত যন্ত্রের ক্লাস্টার কাজ করে। পর্ব ৫৩-এ এর OS-দিকটি দেখবেন।

৬ · Real-time আর embedded OS — সময়ই যেখানে সঠিকতা

সাধারণ OS-এর কাছে আমরা চাই “গড়ে দ্রুত”. কিন্তু কিছু সিস্টেমে গড় দিয়ে চলে না। গাড়ির airbag-কে ধাক্কা লাগার পর কয়েক ডজন মিলিসেকেন্ডের মধ্যে ফুলতেই হবে — এক সেকেন্ড পরে ফুললে সেটি সঠিক উত্তর নয়, ভুল উত্তর। Real-time OS (RTOS)-এ তাই সঠিকতা দুই অংশের: ফল ঠিক হতে হবে, এবং নির্দিষ্ট সময়সীমার (deadline) মধ্যে আসতে হবে।

RTOS-এর নকশার মূল কথা নির্ধারণযোগ্যতা (determinism) — সবচেয়ে খারাপ অবস্থায় (worst case) কতক্ষণ লাগবে, তা আগে থেকে জানা ও প্রমাণ করা যায়। এজন্য RTOS সাধারণত কঠোর priority-ভিত্তিক preemptive scheduling ব্যবহার করে, interrupt দ্রুত সামলায়, আর অনির্ধারিত সময় নেয় এমন কৌশল (যেমন demand paging বা অনিয়ন্ত্রিত মেমরি বরাদ্দ) এড়িয়ে চলে। Trade-off পরিষ্কার: গড় গতি আর সুবিধা কম, কিন্তু নিশ্চয়তা বেশি। পরিচিত RTOS: VxWorks, QNX, FreeRTOS, Zephyr. সাধারণ Linux-কেও আংশিক real-time করার PREEMPT_RT প্যাচ বহু বছর পর ২০২৪ সালে মূল kernel-এ (Linux 6.12) যুক্ত হয় — তবু hard real-time নিশ্চয়তার জন্য সাধারণত বিশেষায়িত RTOS-ই বেছে নেওয়া হয়। Rate-monotonic আর EDF scheduling-এর গণিত পর্ব ২০-এ।

Embedded OS

আপনার বাসার ওয়াশিং মেশিন, মাইক্রোওয়েভ, Wi-Fi রাউটার, স্মার্ট টিভি, ডিজিটাল মিটার — প্রত্যেকটির ভেতরে একটি কম্পিউটার আছে যা নির্দিষ্ট একটি কাজের জন্য বানানো। এগুলোকে বলে embedded system. এদের OS-এর বৈশিষ্ট্য: খুব কম মেমরি (কখনো মাত্র কয়েক কিলোবাইট), কম বিদ্যুৎ, ব্যবহারকারীর সাথে সামান্য বা কোনো ইন্টারফেস নেই, আর বছরের পর বছর রিস্টার্ট ছাড়া চলা। ছোট যন্ত্রে প্রায়ই OS-ই থাকে না — একটি লুপ সরাসরি হার্ডওয়্যার চালায় (bare-metal); একটু বড় হলে FreeRTOS বা Zephyr-এর মতো RTOS; আর রাউটার বা স্মার্ট টিভির মতো বড় যন্ত্রে প্রায়ই embedded Linux (যেমন OpenWrt). Embedded মানে সবসময় real-time নয় — রাউটারের deadline কঠোর নয়, কিন্তু pacemaker-এর আছে।

৭ · মোবাইল আর ক্লাউড — হাতের ফোন থেকে ডেটা সেন্টার

মোবাইল OS

২০০০-এর দশকে Symbian, BlackBerry OS আর Windows Mobile-এর মতো ফোন-OS ছিল। কিন্তু মোড় ঘোরায় ২০০৭ সালে Apple-এর iPhone (তার OS তখন “iPhone OS”, পরে iOS) আর ২০০৮ সালে প্রথম Android ফোন (HTC Dream, যা T-Mobile G1 নামেও পরিচিত)। বিভিন্ন জরিপ অনুযায়ী আজ বাংলাদেশসহ বেশিরভাগ দেশে স্মার্টফোনের বড় অংশ চলে Android-এ। মোবাইল OS-এর অগ্রাধিকারগুলো ডেস্কটপ থেকে আলাদা:

• ব্যাটারি সবার আগে: পর্দা বন্ধ হলে অ্যাপকে ঘুম পাড়িয়ে রাখা, CPU-র গতি কমানো, পেছনের কাজ একসাথে জড়ো করে চালানো।
• মেমরি কম, swap প্রায় নেই: জায়গা ফুরোলে OS পেছনের অ্যাপকে নিজেই বন্ধ করে দেয় — Android-এ low-memory killer; অ্যাপকে তাই যেকোনো মুহূর্তে বন্ধ হওয়ার জন্য তৈরি থাকতে হয়।
• কঠোর নিরাপত্তা: প্রতিটি অ্যাপ আলাদা sandbox-এ; ক্যামেরা, লোকেশন, কন্টাক্ট — প্রতিটির জন্য আলাদা অনুমতি। আপনার মোবাইল ব্যাংকিং অ্যাপের ডেটা অন্য অ্যাপ পড়তে পারে না।
• স্পর্শ, সেন্সর আর রেডিও: touch screen, GPS, accelerometer, মোবাইল নেটওয়ার্ক — সবই OS-এর পরিচালনায়।

ক্লাউড আর virtualization

শেষ বড় পরিবর্তনটি এসেছে ডেটা সেন্টারে। একটি শক্তিশালী সার্ভারকে একজন গ্রাহককে দিলে বেশিরভাগ সময় সেটি অলস থাকে — multiprogramming-এর পুরোনো সমস্যা, শুধু বড় আকারে! সমাধানও পুরোনো চিন্তার নতুন রূপ: একটি যন্ত্রে অনেকগুলো virtual machine (VM) চালানো, প্রত্যেকটি ভাবে সে একটি পূর্ণ কম্পিউটার, নিজের আলাদা OS-সহ। VM-গুলোকে পরিচালনা করে hypervisor:

• Type 1 (bare-metal): সরাসরি হার্ডওয়্যারের ওপর চলে, নিজেই একরকম ছোট OS — VMware ESXi, Xen, Microsoft Hyper-V; Linux-এর KVM kernel-কেই hypervisor বানিয়ে দেয়। ক্লাউড ডেটা সেন্টার এগুলোর ওপর চলে।
• Type 2 (hosted): আপনার সাধারণ OS-এর ওপর একটি অ্যাপ হিসেবে চলে — VirtualBox, VMware Workstation. শেখা আর পরীক্ষার জন্য সুবিধাজনক।

ধারণাটি নতুন নয়: IBM ১৯৬০-এর দশকের শেষে CP/CMS আর ১৯৭২ সালে VM/370-এ virtual machine চালাত। x86 যন্ত্রে এটি জনপ্রিয় হয় ১৯৯০-এর দশকের শেষে VMware দিয়ে; ২০০৩ সালে আসে Xen, আর ২০০৭ সালে KVM Linux kernel-এর অংশ হয়। ২০০৬ সালে Amazon EC2 ঘণ্টা ধরে VM ভাড়া দেওয়া শুরু করলে “cloud computing” মূলধারায় আসে। এরপর আসে আরও হালকা container (Docker, ২০১৩) — এখানে প্রতিটি অ্যাপের আলাদা OS নেই, সবাই একটিই host kernel ভাগ করে, শুধু চোখে আলাদা দেখায়। পার্থক্যটি নিচের কোডে নিজেই দেখবেন। VM আর container-এর ভেতরের কাজ পর্ব ৫০–৫২-তে।

এবার দেখা যাক আপনার কোড যে Linux যন্ত্রে চলছে, তার kernel কোনটি আর কয়টি CPU আছে। নিচের bash কমান্ডগুলো একটি সার্ভারের container-এ চলে:

# এই যন্ত্রের kernel আর CPU — মানগুলো যন্ত্রভেদে আলাদা হবে
echo "Kernel name    : $(uname -s)"
echo "Kernel release : $(uname -r)"
echo "Machine (arch) : $(uname -m)"
echo "nproc          : $(nproc)"
echo "/proc/cpuinfo  : $(grep -c '^processor' /proc/cpuinfo) processor entries"
grep -m1 'model name' /proc/cpuinfo
cut -d' ' -f1-3 /proc/version
grep '^PRETTY_NAME' /etc/os-release

Kernel name    : Linux
Kernel release : 6.8.0-137-generic
Machine (arch) : x86_64
nproc          : 2
/proc/cpuinfo  : 2 processor entries
model name	: AMD EPYC-Rome Processor
Linux version 6.8.0-137-generic
PRETTY_NAME="Ubuntu 24.04.1 LTS"

অন্য OS-এ একই তথ্য দেখার কমান্ড আলাদা — Linux-এর কমান্ড সেখানে সরাসরি চলবে না:

PS> [System.Environment]::OSVersion.Version
Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      26100  0
PS> $env:NUMBER_OF_PROCESSORS
8

Windows 11-ও নিজেকে ভেতরে “10.0” বলে, আলাদা হয় শুধু build নম্বরে (Windows 11 হলে সাধারণত 22000 বা তার বেশি) — এটা ইচ্ছাকৃত, পুরোনো প্রোগ্রাম যাতে version দেখে বিভ্রান্ত না হয়। macOS-এ Terminal-এ uname -r দেয় Darwin kernel-এর version (macOS-এর বাজারি নম্বর নয়), আর CPU সংখ্যা দেখায় sysctl -n hw.ncpu. ওপরের সংখ্যাগুলো একটি উদাহরণমাত্র।

সব প্রজন্ম এক নজরে

নিচের ডায়াগ্রামে প্রতিটি যুগের মূল সমস্যা আর OS-এর জবাব একসাথে দেখুন। লক্ষ্য করুন, প্রতিটি জবাব পরের যুগের নতুন সমস্যার জন্ম দিয়েছে:

৮ · দুটি বড় বংশ — Unix আর Windows

আজকের প্রায় সব কম্পিউটার, ফোন আর সার্ভার দুটি বংশের কোনো একটি থেকে এসেছে। বংশলতিকা জানা থাকলে বুঝবেন কেন Mac-এর Terminal-এ Linux-এর মতো কমান্ড চলে, অথচ Windows-এ চলে না।

Multics (১৯৬০-এর দশক, MIT + GE + Bell Labs)
  └─ Unix — Bell Labs, ১৯৬৯ (Ken Thompson, Dennis Ritchie, PDP-7)
       ├─ ১৯৭৩: kernel C ভাষায় নতুন করে লেখা
       ├─ BSD — UC Berkeley, ১৯৭০-এর দশকের শেষ থেকে
       │    ├─ FreeBSD, NetBSD, OpenBSD
       │    └─ NeXTSTEP (BSD + Mach) ─┐
       ├─ System V — AT&T, ১৯৮৩     │
       │    └─ Solaris, AIX, HP-UX     │
       └─ POSIX মান — IEEE, ১৯৮৮      │
                                       ▼
            macOS / iOS — Darwin, XNU kernel (Mach + BSD)

GNU প্রকল্প (১৯৮৩) + Linux kernel (১৯৯১)
  └─ GNU/Linux distro: Debian, Ubuntu, Fedora, RHEL …
  └─ Android — Linux kernel-এর ওপর (২০০৮)

MS-DOS (১৯৮১, IBM PC)
  └─ Windows 1.0 – 3.x (১৯৮৫–৯২) — DOS-এর ওপর গ্রাফিক্যাল স্তর
       └─ Windows 95 / 98 / ME (১৯৯৫–২০০০) — “9x”, এখনো DOS-নির্ভর

Windows NT 3.1 (১৯৯৩) — একেবারে নতুন kernel (Dave Cutler-এর দল)
  └─ NT 4.0 → Windows 2000 (ব্যবসার জন্য)
       └─ Windows XP (২০০১) — ঘরের আর অফিসের দুই ধারা এক হলো NT-তে
            └─ Vista → 7 → 8 → 10 (২০১৫) → 11 (২০২১)
                 └─ সবই NT kernel-এর উত্তরসূরি

Unix: ছোট, সরল, বহনযোগ্য

Multics থেকে বেরিয়ে আসার পর ১৯৬৯ সালে Bell Labs-এর Ken Thompson আর Dennis Ritchie একটি অব্যবহৃত PDP-7 যন্ত্রে অনেক ছোট একটি OS লেখেন। নামটি Multics-এর ওপর একটি রসিকতা — “Unics”, পরে Unix. এর দর্শন: প্রতিটি প্রোগ্রাম একটি কাজ ভালোভাবে করবে, আর ছোট প্রোগ্রামগুলো pipe দিয়ে জুড়ে বড় কাজ হবে (পর্ব ০৩ আর ১২-এ দেখবেন)। ১৯৭৩ সালে Unix-এর kernel নতুন তৈরি C ভাষায় আবার লেখা হয় — তখনকার দিনে OS লেখা হতো assembly-তে, তাই এটি ছিল বিপ্লব। ফল: Unix যেকোনো নতুন যন্ত্রে নেওয়া সহজ হলো, শুধু C compiler থাকলেই চলে।

AT&T তখন আইনগত কারণে কম্পিউটার ব্যবসায় নামতে পারছিল না, তাই বিশ্ববিদ্যালয়গুলোকে সামান্য খরচে source code-সহ Unix দেয়। UC Berkeley তাতে নিজেদের উন্নতি যোগ করে BSD তৈরি করে — virtual memory, আর ইন্টারনেটের TCP/IP-এর একটি অত্যন্ত প্রভাবশালী বাস্তবায়ন। অন্যদিকে AT&T বাণিজ্যিক System V (১৯৮৩) আনে। নানা কোম্পানির নিজস্ব Unix (Solaris, AIX, HP-UX…) পরস্পরের সাথে পুরো মিলত না; তাই ১৯৮৮ সালে IEEE POSIX মান প্রকাশ করে — একটি সাধারণ system call আর shell-এর চুক্তি, যা মানলে প্রোগ্রাম সব Unix-ধাঁচের OS-এ চলে। এই কোর্সের fork, exec, pthread — সবই POSIX.

GNU, Linux আর বাকি গল্প

১৯৮৩ সালে Richard Stallman ঘোষণা দেন GNU প্রকল্পের — সম্পূর্ণ মুক্ত (free software) একটি Unix-সদৃশ OS. ১৯৯০ সালের মধ্যে compiler (GCC), shell, editor, library — প্রায় সব তৈরি, শুধু kernel (Hurd) পিছিয়ে ছিল। ১৯৯১ সালে ফিনল্যান্ডের ছাত্র Linus Torvalds শখের প্রকল্প হিসেবে একটি kernel লিখে ইন্টারনেটে ঘোষণা দেন। GNU-র টুল আর Linux kernel মিলে তৈরি হলো একটি পূর্ণ মুক্ত OS — অনেকে একে GNU/Linux বলেন। আজ Linux চলে বেশিরভাগ ওয়েব সার্ভার আর ক্লাউড VM-এ, বিশ্বের শীর্ষ supercomputer-গুলোতে, আর kernel হিসেবে প্রতিটি Android ফোনে। (Android-এ Linux kernel থাকলেও userland GNU নয় — সেখানে Google-এর নিজস্ব library আর runtime.)

অন্যদিকে Apple থেকে বেরিয়ে Steve Jobs NeXT কোম্পানিতে তৈরি করেন NeXTSTEP — Mach microkernel আর BSD-র অংশ মিলিয়ে। ১৯৯৭ সালে Apple NeXT কিনে নেয়, আর NeXTSTEP থেকে জন্ম নেয় Mac OS X (২০০১)। তার কেন্দ্র Darwin, যার kernel XNU — Mach আর BSD-র সংকর। iOS, iPadOS, watchOS — সবই এই একই কেন্দ্রের ওপর। তাই macOS-এর বেশ কিছু সংস্করণ আনুষ্ঠানিক UNIX সনদ পেয়েছে, আর Linux “Unix-সদৃশ” — কোডে Unix-এর বংশধর নয়, কিন্তু আচরণে ও মানে (POSIX) কাছাকাছি।

Windows: দুটি ধারা, তারপর এক

Microsoft-এর যাত্রা শুরু ১৯৮১ সালে IBM PC-র জন্য MS-DOS দিয়ে — একক ব্যবহারকারী, একক কাজ, মেমরি-সুরক্ষা নেই। Windows 1.0 থেকে 3.x ছিল DOS-এর ওপর একটি গ্রাফিক্যাল স্তর। Windows 95, 98 আর ME (একসাথে “Windows 9x”) অনেক আধুনিক হলেও ভেতরে DOS-এর উত্তরাধিকার বয়ে চলত — একটি খারাপ প্রোগ্রাম পুরো সিস্টেম ফেলে দিতে পারত, সেই কুখ্যাত “নীল পর্দা” প্রায়ই দেখা যেত।

সমান্তরালে Microsoft DEC-এর VMS OS-এর অভিজ্ঞ প্রকৌশলী Dave Cutler-কে নিয়ে শূন্য থেকে নতুন একটি OS বানায় — Windows NT (১৯৯৩ সালে NT 3.1). NT শুরু থেকেই ৩২-বিট, preemptive multitasking, প্রতিটি প্রসেসের সুরক্ষিত মেমরি, ফাইলে অনুমতির ব্যবস্থা (NTFS), আর একাধিক CPU-র সমর্থন নিয়ে আসে। প্রায় এক দশক দুটি ধারা পাশাপাশি চলে — ঘরের জন্য 9x, অফিস ও সার্ভারের জন্য NT/2000. ২০০১ সালে Windows XP দিয়ে ঘরের ব্যবহারকারীরাও NT kernel-এ চলে আসেন। আজকের Windows 10 আর 11 সেই NT-রই উত্তরসূরি — ভেতরের খুঁটিনাটি পর্ব ৫৬-তে।

৯ · AI-এর যুগে — OS-এর ইতিহাস আর কমান্ড যাচাই করা

AI-কে “Windows NT কবে এসেছে” বা “আমার CPU কয়টি দেখার কমান্ড কী” জিজ্ঞেস করলে সাধারণত দ্রুত উত্তর পাবেন। কিন্তু এই বিষয়ে AI-এর কয়েকটি পরিচিত দুর্বলতা আছে, যা জানা থাকলে আপনি সময় ও ঝামেলা দুটোই বাঁচাবেন।

AI-এর দেওয়া ইতিহাস বা কমান্ড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কমান্ডটি আমার OS আর distro-র জন্য কি না দেখেছি — Linux, macOS আর Windows-এর কমান্ড আলাদা
• চালানোর আগে man পাতা বা --help পড়ে প্রতিটি option বুঝেছি
• sudo, chmod 777 বা কিছু মুছে ফেলার কমান্ড এলে থেমে কারণ জিজ্ঞেস করেছি
• সাল আর নাম অন্তত দুটি নির্ভরযোগ্য উৎসে মিলিয়েছি
• সংখ্যার উত্তর (যেমন 1 − pⁿ) নিজে হাতে বা ছোট কোডে আবার হিসাব করেছি, আর সূত্রের অনুমানগুলো লিখে রেখেছি