ඩෙස්ක්ටොප් වාදවිවාදවලින් ඔබ්බට
දශක ගණනාවක් තිස්සේ Linux සහ Windows අතර තිබෙන මතභේදය දෙස බොහෝ දෙනා බැලුවේ desktop භාවිතය, gaming පහසුකම් හෝ licensing ක්රමවේදයන් වැනි සරල කාරණා ඔස්සේය. නමුත් software engineers ලා, systems architects ලා සහ DevOps වෘත්තිකයන් ලෙස අපට මෙවැනි සරල සංසන්දනයන්ගෙන් ප්රයෝජනයක් නැත. සැබෑ වෙනස පවතින්නේ මේ operating systems වල kernel architecture, process management, file system design සහ අධික workload එකක් යටතේ system resources හසුරුවන ආකාරය වැනි ගැඹුරු තාක්ෂණික කරුණු තුලය.
මෙම ලිපියෙන් අප බලාපොරොත්තු වන්නේ marketing ප්රචාරණයන්ගෙන් ඔබ්බට ගොස්, Linux සහ Windows NT වල මූලික ඉංජිනේරුමය සැලසුම් සහ ඒවා production environments වලදී ක්රියා කරන ආකාරය පිළිබඳව ගැඹුරින් සාකච්ඡා කිරීමටයි.
1. Kernel Architecture: Monolithic vs. Hybrid
Linux සහ Windows අතර ඇති ප්රධානතම ව්යුහාත්මක වෙනස පවතින්නේ ඒවායේ kernel සැලසුම් කර ඇති ආකාරය මතයි. මෙම සැලසුම මඟින් drivers ක්රියාත්මක වන ආකාරය, system calls හසුරුවන ආකාරය සහ memory සීමාවන් පාලනය වන ආකාරය තීරණය වේ.
The Linux Monolithic Kernel
Linux භාවිතා කරන්නේ monolithic kernel architecture එකකි. මෙම සැලසුමේදී මුළු operating system එකම ක්රියාත්මක වන්නේ kernel space (Ring 0) එක තුලයි. මෙයට process scheduler, memory manager, virtual file system, network stack සහ device drivers ඇතුලත් වේ.
සියලුම උපාංග එකම address space එකක් තුල ක්රියාත්මක වන බැවින්, subsystems අතර සන්නිවේදනය ඉතා කාර්යක්ෂම වේ. උදාහරණයක් ලෙස, device driver එකකට network stack එක හෝ file system එක සමඟ සන්නිවේදනය කිරීමට විශාල කාලයක් වැයවන context switches සිදු කිරීමට අවශ්ය නොවේ; එය සෘජුවම Ring 0 තුල function calls මඟින් සිදු කෙරේ.
මෙහි ඇති ප්රධානම අවාසිය නම් stability (ස්ථායීතාවය) පිළිබඳ ප්රශ්නයයි. Monolithic kernel එකක් තුල ක්රියාත්මක වන තෙවන පාර්ශවීය graphics driver එකක දෝෂයක් (bug) ඇති වුවහොත්, එය මුළු kernel memory එකම අඩාල කරමින් kernel panic එකක් ඇති කර මුළු system එකම crash කිරීමට ඉඩ ඇත. නමුත් Linux විසින් code review ක්රියාවලීන් සහ dynamic kernel module loading (LKM) තාක්ෂණය මඟින් මෙම අවදානම අවම කර ඇත. මේ නිසා system එක reboot කරන්නේ නැතිව modules load සහ unload කිරීමට හැකියාව ලැබේ.
The Windows NT Hybrid Kernel
Windows NT භාවිතා කරන්නේ hybrid kernel architecture එකකි. මෙහිදී monolithic සහ microkernel යන සැලසුම් දෙකෙහිම ලක්ෂණ අඩංගු වේ. මෙහි ප්රධාන kernel (microkernel) එක මඟින් low-level synchronization, thread scheduling සහ interrupt handling සිදු කරන අතර, එය වටා ඇති NT Executive මඟින් memory management, security සහ I/O subsystems පාලනය කරනු ලබයි.
මෙහිදී වැදගත්ම කරුණ නම් Windows විසින් ඇතැම් services සහ drivers වෙන් කර (isolate) තැබීමයි. වැදගත් drivers තවමත් performance ලබා ගැනීම සඳහා Ring 0 තුල ක්රියාත්මක වන අතර, printer drivers වැනි user-mode drivers සහ subsystems ක්රියාත්මක වන්නේ user space (Ring 3) තුලයි. මෙමඟින් user-mode driver එකක් crash වුවද මුළු operating system එකම crash වීම වැළකේ.
කෙසේ වෙතත්, මෙම වෙන් කිරීම නිසා යම් overhead එකක් ඇති වේ. User-mode component එකකට kernel-mode component එකක් සමඟ සන්නිවේදනය කිරීමට අවශ්ය වූ විට, system එකට user mode සහ kernel mode අතර මාරු වීමට සිදු වේ. මෙහිදී register states save කිරීම සහ translation lookaside buffers (TLB) flush කිරීම වැනි අමතර කාර්යයන් සිදු කිරීමට සිදු වේ.
2. Process සහ Thread Execution Models
Operating system එකක් මඟින් processes නිර්මාණය කරන, schedule කරන සහ පාලනය කරන ආකාරය අනුව applications නිර්මාණය කරන ආකාරය වෙනස් වේ. Linux සහ Windows concurrency හසුරුවන ආකාරය මෙයට හොඳම උදාහරණයකි.
Linux: "Everything is a Task" සංකල්පය
Linux kernel එක තුල processes සහ threads අතර පැහැදිලි ව්යුහාත්මක වෙනසක් නොමැත. මේ දෙකම හඳුන්වන්නේ struct task_struct නැමැති එකම internal data structure එකකිනි. සරලවම කිවහොත්, process එකක් යනු තමන්ටම ආවේණික address space එකක් ඇති task එකක් වන අතර, thread එකක් යනු තම parent task එක සමඟ address space එක share කරගන්නා task එකකි.
Linux හි නව processes නිර්මාණය කරන්නේ fork() system call එක මඟිනි. මෙහිදී ඉතාමත් කාර්යක්ෂම Copy-on-Write (COW) ක්රමවේදයක් භාවිතා වේ. ඔබ process එකක් fork කල සැනින් kernel එක මඟින් parent process එකේ physical memory එක child process එකට copy නොකරයි. ඒ වෙනුවට, දෙදෙනාම එකම physical memory pages share කරගන්නා අතර ඒවා read-only ලෙස සලකුණු කෙරේ. Physical memory පිටපත් කරනු ලබන්නේ යම් process එකක් එම memory එකට write කිරීමට උත්සාහ කලහොත් පමණි.
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
printf("Child process executing with copy-on-write memory\n");
} else if (pid > 0) {
printf("Parent process continuing execution\n");
}
return 0;
}
Threads නිර්මාණය කරනු ලබන්නේ clone() system call එක මඟිනි. එමඟින් parent සහ child අතර share කරගත යුතු resources (address space, file descriptors, signal handlers) මොනවාද යන්න නිවැරදිව පාලනය කල හැක.
Windows: Rigid Process/Thread ධුරාවලිය
Windows operating system එක තුල processes සහ threads අතර දැඩි වෙනසක් පවතී. Windows හි process එකක් යනු Executive Process (EPROCESS) block එකක් මඟින් නිරූපණය වන විශාල container object එකකි. එය සෘජුවම code execute නොකරන අතර, ඒ වෙනුවට එහි threads එකක් හෝ කිහිපයක් (ETHREAD blocks) අඩංගු වේ. Kernel එක මඟින් schedule කර ක්රියාත්මක කරනු ලබන්නේ මෙම threads වේ.
Windows හි CreateProcess() API එක මඟින් process එකක් නිර්මාණය කිරීම සාපේක්ෂව බරපතල (heavy) ක්රියාවලියකි. OS එක මඟින් process object එකක් allocate කර, executable image එක load කර, DLL dependencies පරීක්ෂා කර, virtual memory space එක සකසා ප්රථම thread එක නිර්මාණය කල යුතුය. මෙම overhead එක නිසා Windows applications වලදී නව processes නිර්මාණය කරනවා වෙනුවට thread pools භාවිතා කිරීමට වැඩි නැඹුරුවක් දක්වයි.
3. File System Architecture සහ I/O Models
Databases සහ web servers වැනි high-throughput applications වල performance සඳහා file system design එක සහ Input/Output (I/O) handling ක්රමවේදය අතිශයින්ම බලපායි.
Linux: Virtual File System (VFS) සහ Inodes
Linux විසින් සියලුම storage devices, Virtual File System (VFS) layer එක මඟින් abstract කරනු ලබයි. VFS මඟින් පොදු interface එකක් ලබා දෙන අතර, එමඟින් user-space applications වලට standard POSIX system calls (open, read, write) භාවිතයෙන් විවිධ file systems (ext4, XFS, Btrfs) සමඟ ගනුදෙනු කල හැක.
ext4 වැනි Linux file systems වල, files නිරූපණය කරන්නේ inodes (index nodes) මඟිනි. Inode එකක file එකේ ප්රමාණය, permissions, timestamps සහ disk එකේ data blocks වලට අදාල pointers වැනි metadata අඩංගු වන නමුත් එහි file name එක අඩංගු නොවේ. Directory entries (dentries) මඟින් සිදු කරන්නේ file name එක අදාල inode number එකට map කිරීමයි. මෙම ක්රමය නිසා hard links වැනි පහසුකම් (එනම් එකම inode එකට විවිධ file names පෙන්වීම) ඉතා පහසුවෙන් සිදු කල හැක.
High-performance I/O multiplexing සඳහා Linux සතුව epoll system call එක පවතී. එමඟින් එක thread එකකට busy-waiting වලින් තොරව file descriptors දහස් ගණනක් කාර්යක්ෂමව නිරීක්ෂණය කල හැක. Nginx වැනි වේගවත් web servers වල පදනම මෙයයි.
// Example of setting up epoll for non-blocking I/O
int epoll_fd = epoll_create1(0);
struct epoll_event event;
event.events = EPOLLIN | EPOLLET; // Edge-triggered
event.data.fd = server_socket;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, server_socket, &event);
Windows: NTFS සහ I/O Completion Ports (IOCP)
Windows ප්රධාන වශයෙන් භාවිතා කරන්නේ NTFS (New Technology File System) file system එකයි. ext4 මෙන් නොව, NTFS ක්රියා කරන්නේ Master File Table (MFT) එකක් පදනම් කරගෙනය. NTFS volume එකක ඇති සෑම file එකකටම සහ directory එකකටම MFT තුල අවම වශයෙන් එක record එකක්වත් පවතී. එහි metadata සහ ඉතා කුඩා files වල data (resident attributes) අඩංගු වේ.
NTFS සතුව object identifiers, transactional NTFS සහ Alternate Data Streams (ADS) වැනි දියුණු පහසුකම් පවතී. කෙසේ වෙතත්, Linux වල ඇති සරල VFS/inode model එකට සාපේක්ෂව NTFS වල file path handling සහ security descriptor lookups සඳහා වැඩි CPU overhead එකක් වැය වේ.
Asynchronous I/O සඳහා Windows භාවිතා කරන්නේ I/O Completion Ports (IOCP) තාක්ෂණයයි. Events සඳහා දිගින් දිගටම poll කරනවා වෙනුවට, application එකක් මඟින් I/O completion port එකක් register කරනු ලබන අතර asynchronous read හෝ write එකක් අවසන් වූ සැනින් Windows kernel එක මඟින් worker threads දැනුවත් කරනු ලබයි. IOCP ඉතා ඉහල scalability එකක් ලබා දෙන අතර Microsoft SQL Server සහ IIS, Windows තුල ඉතා හොඳින් ක්රියා කිරීමට ප්රධාන හේතුව මෙයයි.
4. Virtualization සහ Containerization
නූතන cloud computing ක්ෂේත්රය containerization මත පදනම් වී ඇත. Linux සහ Windows virtualization සඳහා සහය දක්වන ආකාරය දෙස බැලීමෙන් ඒවායේ සැලසුම්කරණ ප්රමුඛතා වටහා ගත හැක.
Native Linux Containers
Containers යනු Linux සඳහාම ආවේණික (native) තාක්ෂණයකි. Docker container එකක් යනු virtual machine එකක් නොවේ; එය host kernel එක මත සෘජුවම ධාවනය වන, ප්රධාන kernel පහසුකම් දෙකක් මඟින් isolate කරන ලද සාමාන්ය Linux process එකක් පමණි:
- Namespaces: Process එකකට පෙනෙන system resources (PID, Network, Mount, IPC, User) වෙන් කර තබයි.
- Control Groups (cgroups): Processes සමූහයක් සඳහා භාවිතා කල හැකි resource සීමාවන් (CPU, Memory, Disk I/O, Network bandwidth) පාලනය කරයි.
Hypervisor overhead එකක් නොමැති බැවින්, Linux containers මිලිතත්පර කිහිපයකින් start වන අතර ඉතා ඉහල performance එකක් ලබා දෙයි.
Windows Containers සහ WSL2
Windows සඳහා මෑතක් වන තුරුම native containerization පහසුකම් නොතිබුණි. දැනට Windows Containers ක්රම දෙකකට ක්රියාත්මක වේ:
- Process Isolation: Linux මෙන් containers විසින් host Windows kernel එක share කරගනු ලබයි. මෙහිදී container base image එක සහ host OS version එක එකම විය යුතුය.
- Hyper-V Isolation: සෑම container එකක්ම වෙනමම ක්රියාත්මක වන සැහැල්ලු utility virtual machine එකක් තුල ධාවනය වන අතර, ඒ සඳහා වෙනමම Windows kernel එකක් පවතී. මෙයට වැඩි memory ප්රමාණයක් සහ වැඩි කාලයක් වැය වේ.
Linux මත පදනම් වූ development කටයුතු පහසු කිරීම සඳහා Microsoft විසින් Windows Subsystem for Linux (WSL2) හඳුන්වා දෙන ලදී. මෙහිදී සිදු කරන්නේ Linux system calls, Windows වලට translate කිරීම නොවේ. ඒ වෙනුවට, ඉතාමත් optimized කරන ලද සැබෑ Linux kernel එකක් සැහැල්ලු Hyper-V virtual machine එකක් තුල ධාවනය කිරීමයි. එමඟින් Windows පරිශීලකයින්ට native Linux performance ලබා ගැනීමට මඟ පෑදේ.
Conclusion: නිවැරදි මෙවලම තෝරා ගැනීම
නූතන මෘදුකාංග ඉංජිනේරු විද්යාවේදී Linux සහ Windows අතරින් එකක් තෝරා ගැනීම පුද්ගලික කැමැත්ත මත පමණක් තීරණය කල නොහැක. එය ඔබගේ application එකෙහි ව්යුහය සහ operating system එකෙහි ශක්තීන් මත තීරණය විය යුත්තකි.
ඉතා විශාල ලෙස horizontal scale කල යුතු, cloud-native containerized deployments සහ අඩු resource ප්රමාණයක් භාවිතයෙන් සෘජුවම hardware access ලබා ගත යුතු අවස්ථාවන් සඳහා Linux විශිෂ්ට වේ. අනෙක් අතට, විශාල පරිමාණයේ enterprise-grade directory services, Microsoft ecosystem එක සමඟ සෘජු සම්බන්ධතාවය සහ විශාල enterprise සේවාවන් සඳහා optimized කරන ලද asynchronous I/O අවශ්යතා සඳහා Windows NT ඉතා සුදුසු වේ.


