GNU OS, Linux, Hurd Monolithic Kernel, Micro Kernel

GNU OS එකට තියෙන එකම Kernel එක monolithic kernel එකක් වන linux විතරක් නෙවෙයි නමුත් හොඳටම implement කරපු එක linux kernel එක. GNU OS එක සතුව Hurd කියන multi server micro kernel එකත් සතුයි, monolithic kernel වල තියෙන ගැටළු නිසා තව අවුරුදු විසිපහකින් linux kernel එක සුදුසු නැහැ හොඳට implement කරපු micro kernel එකක් තමා පාවිච්චි කරන්න ඕන කිඋවොත්......? මේ දෙකේ වාසි අවාසි තියෙනවා, ඕක ගැන වාද විවාද, මරාගැනීම් ගොඩක් තියෙනවා මගේ අරමුණ ඒක ගැන වාද පවත්වන එක නෙවයි, ඕන නම් "ටනෙන්බොම් - ටොර්වල්ඩ්ස් විවාදයේ" (The Tanenbaum - Torvalds debate) කැමති පාර්ශවයක් ගන්න  (*අපි නැහැ ඕවට ).
GNU hurd කියලා GNU match default පාවිච්චි කරන micro kernel එකක් තියෙනවා, අති බහුතරයක් දෙනා Linux OS කියලා වැරදි වැටහීමක ඉන්නවා, 

අපි සරලව Debian GNU, Linux පාවිච්චි කරන, distribution වෙනුවට Debian GNU Hurd, පාවිච්චි කරන distribution එක kernel එක ගැන අවබෝද නැති කෙනෙක්ට දුන්නොත්, කියයි ඕක linux කියලා, ඇයි GNU Core utilities ටික ඔක්කොම වැඩකරනවා, ඔය cp, mv ... etc කියලා තියෙන්නේ GNU Core එකේ තියෙන unix replacements, මේවා අයිති kernel එකට නෙවෙයි GNU OS එකට kernel එකෙන් කරන්නේ මේවා execute කරන්න API දෙන එක. උදාහරණයක් විදිහට Hurd පාවිච්චි කරන debian disto එකක uname -a command එකේ result එක Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux වෙනුවට Match1.8+20200421/hurd-0.9 x86_64 GNU/Hurd .

WAP billing

protocol එකක් කියන්නේ data exchange (හුවමාරු) කරගන්න තියෙන method එකක් (ක්‍රමයක්). 
IP - internet protocol, 
SMTP - Simple Mail Transfer Protocol,
FTP - File Transfer Protocol,

ඔයවගේ තියෙන protocol හැට හුටා මාර අස්සේ තියෙනවා WAP  protocol කියලා එකක්, මේක ඇතුලේ තියෙනවා WAP billing කියලා mechanism එකක් මේ mechanism එකෙන් පුළුවන් end user ගේ internet billing එක සම්බන්ද data exchange කරගන්න, සරලව කිඋවොත් web site එක හදපු එකාට පුළුවන් මේ mechanism එකෙන් site එකට එන එකාගේ phone number එක ගන්න. මේ mechanism එක ඉතාම ප්‍රාථමික මට්ටමේ තියෙන එකක් එහෙම කියන්න හේතුව මේකේ නැහැ authentication method එකක්, 

තවත් සරලව කිඋවොත් මෙහෙම හිතමුකෝ මං හදල තියෙනවා wap-billing mechanism එක පාවිච්චි කරන site එකක් මේකට එනවා Thimira කියල එකෙක්, Thimira ගෙ MSISDN එක 077123123 කියලා කියමුකෝ නමුත් මූ පොඩි ගේමක් දීල  wap-billing mechanism එකට වෙන MSISDN එකක් පෙන්නනවා, දැන් site එක හදපු මට බැහැ මේ ඇත්තටම Thimira ගේ number එකද කියල තහවුරු කරන්න, නමුත් මට පුළුවන් මට පේන number එකේ billing account එකෙන් සල්ලි කපන්න ISP ට request කරන්න, ඒවගේම මේ mechanism එකේ ක්‍රමයක් නැහැ සල්ලි කපනකොට ඒ වෙනුවෙන් authentication system එකක් හදලා නැත්තම් ඒක manually authenticate කරන්නවත්, ඔන්න ඔහොමයි 1100 පාවිච්චි කරන 70 පැනපු අංකල් ලගේ phone bill එකට තට්ටු වෙන්නෙත්.

ඇත්තටම මේ wap-billing mechanism එක use කරේ බොහොම ඉස්සර ප්‍රයෝජනවත් දේවල් කරන්න, credit/debit card වලින් online ගෙවීම් කරනවා වෙනුවට internet හරහා මුදල් ගෙවීම් කරන්න මේ ක්‍රමේ පාවිච්චි කරා. ඒවගේම internet service දෙන හැම ISP ල අනිත් services වැඩ කරවනව වගේම මේකත් වැඩ කරවනවා, පාරිබෝගිකයාගේ උවමනාව මත. 

දැන් අපි එමු ශ්‍රීලන්කන් ප්‍රශ්නෙට

add touch උන ගමන් hungama, game hub එක එක ඒව, 
දැන් කට්ටියට තේරෙනවා නේ මේක වෙන්නේ කොහොමද කියලා. පාරිබෝගිකයට අයිතියක් තියෙනවා තමන්ට service එකක් අවශ්‍ය නැත්තම් ඒක block කරන්න කියල ISP ගෙන් ඉල්ලීමක් කරන්න, ඔය wap-billing mechanism කතන්දර call center වල ඉන්න ට කියලා වැඩක් නැහැ . කරන්න තියෙන්නේ Email එකට email කරන්න wap billing service එක block කරන්න කියලා. ඔයාගෙ ප්‍රශ්නය technical team එකටදාන්න කියන්න ඔතන email බලන අය  දන්නෙත් නැහැ ඔය wap protocol කතන්දර එනිසා උන් ඔයා කිඋවත් නැතත් Technical Team දානවා. ප්‍රශ්නේ විසඳෙයි. විසඳෙන්නේ නැති තැන මොනවද කරන්න පුළුවන් කියල නීති විශාරදයින්ගෙන් සහය පතන්න. බහුතරයක් දෙනා නොදැනුවත් සහ  අනුදැනුමෙන් තොර භාවිත වෙන මෙම දුර්වල mechanism එක පාරිබෝගික ඉල්ලීමෙන් තොරව active තියෙන්නේ ඇයි කියන එක නම් විමසා බැලිය යුතුයි.  එහෙම තියෙනවා නම් mechanism එකේ flow එකෙන් billing account එකට request එක යන්න කලින් authenticate වෙනවා නම් අවුලක් නැහැ, ප්‍රශ්නය එහෙම authentication එකක් නැතුව නිකන්ම 70 පැනපු අංකල් ලගේ phone bill එකට තට්ටු වෙන එක.    

Filesystem Hierarchy Standard Sinhala

/bin

Purpose  අරමුණ

bin තුල අඩංගු වෙනවා, commands, system administrator සහ users, ට බාවිත කල හැකි, නමුත් මේවා වෙනත් file system mount නොකර ඇති අව්ස්තාවලත් බාවිත කල හැකිවිය යුතුයි, (උදා: Single User Mode එකේදී) මේතුල අඩන්ගුවෙන්න පුළුවන් *commands, scripts හරහා  indirectly බාවිත විය හැකි.
  
*උදා : bzip2 මගින් compress කර ඇති file එකකට grep, command කිරීමට bzgrep, bzegrep යනුවෙන් script එකක් තිබිය හැක
gzip බාවිත කරන uncompress යනුවෙන් script එකක් තිබිය හැක.

historical ඇරියස් නිසා grep -F බාවිත කිරීමට fgrep යනුවෙන් script එකක් තිබිය හැක.

*Shell Wrappers තියෙන්න පුළුවන්, Shell Wrapper එකක් කියන්නේ complex command line program එකකට pass කරන්න ඕන parameters accept කරන shell program එකක්, මේ shell program එක අර original program එකට යවන්න ඕන parameters accept කරලා pass කරනවා, complex program එකක් shell script එකකින් wrap කරාම ඒක invoke කරන්න ඉතාම පහසුයි.  

*උඩ කියපු bzgrep, bzegrep කියන්නේ grep එකේ wrapper programs.

*Single User mode එකට සරල උදාහරණයක් නම් maintenance mode එක සහ run level1  refer කල හැක (මේ පිලිබඳ දීර්ගව පසුවට). මෙහිදී system එක repair කරගැනීමට අවශ්‍ය services සමග අවම මට්ටමෙන් ක්‍රියාත්මක වීමට තිබියයුතුය.

අත්‍යවශ්‍ය නොවන command binaries, /bin  තුල place කිරීම වෙනුවට  /usr/bin තුල place කිරීමට වග බලාගත යුතුය.
උදා. : non root users ලට අවශ්‍ය වන X Window System, chsh ආදිය /bin තුල place නොකළ යුතුය. 

Requirements

There must be no subdirectories in /bin.

සෙමින් update වන ලිපියකි  

Copy කරගැනීමට අවසරය ඇති නමුත් Database එකට රක්තපාතය, RAM වැනි වචන යෙදීම සපුරා තහනම්.

JVM, Dalvic VM, Linux, Android, CPU design architectures RISC CISC සහ CPU architectures.

JVM, Dalvic VM, Linux, Android, CPU design architectures සහ CPU architectures.

අපි මුලින්ම සරලව තේරුම් ගමු Java code එකක් සහ C code එකක් execute වෙන්නේ කොහොමද කියලා.

සරලව පැහැදිලි කරනවා නම් අපි ලියන java code file එකක් Java byte code file එකක් බවට පත් කරලා ඒක .class file එකක store කරනවා එතකොට මේ .class file එකේ තියෙන byte code කියවන්න පුළුවන් Java Virtual Machine එකට. එතකොට Java Virtual Machine එක තමා byte code, native code බවට (On the fly compilation) පත්කරමින් Operating System එකේ තියෙන Kernel (Hardware එක්ක ගනුදෙනු කරන program එක) API එක්ක ගනුදෙනු කරමින් execution එක කරන්නේ.
මේ byte code machine code කරන ක්‍රම දෙකක් තියෙනවා
1 Interpret කරන එක එකියන්නේ line by line පේලියෙන් පේලිය
2 JIT (Just in time) මේකෙදි වෙන්නේ කොටස් කොටස් වශයෙන්
JVM එක මේ දෙකම කරනවා (ඒ ගැන වෙනම ලිපියකුත් මං ලියලා තියෙනවා)
එතකොට C වලින් ලියන code එකකදී වෙන්නේ කෙලින්ම compiler එක native code එකට පත් කරලා ඒක executable file එකක් විදිහට store කරනවා (ඇත්ත කතාව මෙච්චර සරල නහ, තේරුම් ගන්න ඕන නිසා මෙහෙම හිතාගන්න)
එතකොට මෙතැනදී අර Java වලදී වගේ අතර මැද Virtual machine එකක් නැහැ, ඒවගේම මේක Virtual Machine එකක් හරහා execute වෙනවාට වඩා Memory, CPU resources අඩුවෙන් පාවිච්චි කරලා ඉතා වේගයෙන් execute වෙනවා.
එහෙනම් මොකටද virtual machine එකක් දාගෙන දඟලන්නේ කෙලින්ම execute කරන්න පුළුවන් නේ?
ඒකට උත්තරේ ලබාගන්න අපි CPU architecture designs සහ CPU architectures ගැන සරල අවබෝදයක් ලබාගමු.

CPU architecture designs සහ CPU architectures

ප්‍රධාන CPU architecture designs දෙකක් තියෙනවා

1 Complex instruction set computer  (CISC)
2  Reduced instruction set computer (RISC)

අපි මේ පිලිබඳ ඉතාමත් සරල අවබෝදයක් ලබාගමු ලිපියේ ඉතිරි කොටස තේරුම් ගන්න.
Complex Instruction set computer එකකට පුළුවන් instruction set එකක්ම memory ගෙන්නාගෙන multi step operations එකවර කරලා දාන්න. එයාට instruction set ගෙනල්ල තියාගන්න වේනම් units තියෙනවා, එනිසා execution එකේදී  hardware විශාල කාර්යක් කරනවා
Reduced  Instruction set computer එකේදී එක instruction එකක් complete කරන්න CPU cycles වැඩි ප්‍රමාණයක් අවශ්‍ය වෙනවා. ඒවගේම මේවා සම්පූර්ණ කරගන්න මෙයාට යම් කිසි කාලයක් අවශ්‍ය වෙනවා, DRAM වලට යනකොට මෙයාට තව වැඩ වැඩිවෙනවා මොකද සැරින් සැරේ RAM එක charge කරන වැඩෙත් කරන්න ඕන. මෙයා execution එකේදී software මත depend වෙනවා මොකද මෙයාට කියලා දෙන්න ඕන කරන්න ඕන දේවල් එකින් එක.

දැන් අපි බලමු මේ CPU designs දෙක භාවිත වෙන processor architectures මොනවද කියලා
CISC architecture එකේ processor බාවිතා වෙන්නේ Desktop / Server machine වල, ඒවගේම විදුලියත් වැඩිපුර භාවිතා කරනවා මොකද CPU architecture එක complex transistor තොගයක් තියෙනවා අවම 30 watt වත් විදුලි බලයක් පාවිච්චි කරන බලගතු processor තමා තියෙන්නේ. හැබයි hardware වැඩි රාජකාරියක් කරණ නිසා memory (RAM) consumption එක අඩුයි. මොකද තියාගන්න ඕන instruction ප්‍රමාණය අඩුයි.  CISC වලට උදාහරණ අපේ මේස උඩ තියෙන computer වල තියෙන amd64(64bit),  i386(32 bit).
RISC වලට උදාහරණ අපි හැමෝගෙම phone වල තියෙන ARM architecture එක. විදුලිය watt එකකටත් වඩා අඩු ප්‍රමාණයක් බාවිත කරන තැන්වල වගේම අරමුණට අනුව powerful supercomputers වලත් මේවා පාවිච්චි කරනවා. (ත්රුම් ගැනීමට අවශ්‍ය නිසා low-end devices වල පාවිච්චිකරන එක ගැන හිතන්න)(Phones, Tablets, CCTV DVR)

දැන් තේරුම් ගන්න ඕන දේ තමා CISC එකට compile කරපු C program එකක් RISC එකේ run කරන්න බැහැ, සරලව කිඋවොත් computer එකේ run වෙන software එක phone එකට දැම්මොත් run වෙන්නේ නැහැ.
ඇයි...? computer එක CISC architecture එකේ එයා එකපාර instruction සෙට් එකක්ම අරගෙන වැඩේ කරනවා, එයාට ලොකු විදුලි බලයක් එක්ක transistor තොගයක් තියෙනවා, නමුත් phone එක RISC architecture එකේ මෙයාට එකින් එක කියල දෙන්න ඕන මෙයාට ලොකු power එකක් use කරන transistor තොග නැහැ architecture එක simple.
සරලව කිඋවොත් CISC එකට කියන්න ඕන විදිහට නෙවෙයි RISC එකට කියන්න ඕන. එනිසා CISC executable එකක තියෙන binary instructions. RISC processor එකකට තේරුමක් නැතිව යනවා. මේකට අපිට cross compiler එකක් පාවිච්ච් කරලා amd64 එකේ වැඩකරන software එක armel වල වැඩකරන්න cross compile කරන්න පුළුවන්. arm වලට Cross compile කරමා executable එකේ size එක amd64 වලට වඩා ලොකුයි, මොකද binary instruction යවන්න ඕන විදිහ එකින් එක තියාගන්න ඕන(මං කලින් කිඋවා මෙයාගේ execution process එකේ ගොඩක් දේවල් software වල depend වෙනවා කියලා) GNU/Linux download manager එකක් වන area2c, emdebian cross compiler එකෙන් cross compile කරලා armel තියෙන Samsung galaxy phone එකේ execute කරපු එකේ screenshot එකක් (screen shot eka passe daannam)

නමුත්  RISC SOC වල purpose build processors එනවා එකියන්නේ අදාළ instruction set එකක් වෙනුවෙන්ම, මෙහෙම කරනකොට general purpose processor එකට වඩා අඩු විදුලි බලයකින් සහ කාරය්ක්ෂමව වැඩේ වෙනවා මොකද යම්කිසි නිශ්චිත අරමුණක් වෙනුවෙන් processor එක හදල තියෙන නිසා, ඕක සරලව තේරුම් ගන්න 8mp camera එකකින් එන input එක process කරන්න 3ghz cores දෙකක් තියෙන processor එකක් ලොකු මහන්සියක් දරනවා නමුත් 24mp camera එකක් තියෙන smart phone එකක් මේ වැඩේ ගේමක් නැතුව කරන්නේ එයාට ඒ වැඩේ කරන්න වෙනම SOC එක ඇතුලෙම chip එකක් තියෙනවා. එතකොට video production කරන අය? ඒ අය අමතර capture card එකක් ගහන්නේ ඒ වැඩේ general purpose processor එකට දෙන්නේ නැතුව capture card එකේ තියෙන purpose build processor එකට දෙන්න. තවත් සරලව කිඋවොත් මිටියකින් ඇනයක් ගහන්නත් පුළුවන් ගේමක් දීල ගලවන්නත් පුළුවන්, නමුත් එකට ඇන ගලවන උපකරණයක් තිබ්බොත් ඇනේ ගේමක් නැතුව ගලවන්න පුළුවන්. 

දැන් අපි එමු අපේ පලවෙනි ප්‍රශ්නෙට කෙලින්ම execute කරන්න පුළුවන් කම තියෙද්දී ඇයි Virtual Machine එකක්,
උදාහනයකට අපි JAVA Virtual machine එක ගමු JVM එක ලෝකේ තියෙන එක එක processor architecture වලට වැඩ කරන්න හදන එක JVM දියුණු කරන කට්ටියගේ වැඩක්, application එක පාවිච්චි කරන කෙනා processor architecture ගැනවත් cross compiler ගැනවත් දුක්වෙන්නවත් ඒක ගැන ඉගෙනගන්න මහන්සිවෙන්නවත් අවශ්‍ය නැහැ  එයාට තියෙන්නේ අදාළ application එක jvm එක බාවිතයෙන් run කරන්න විතරයි JVM එක operating system එකත් එක්ක බලාගයි application එක කොහොමද execute කරන්නේ කියල.
ඒවගේම හිතන්න අවුරදු 10 ක ලොකු project එකක් කරාට පස්සේ system එකේ processor එකක් මාරු කරන්න උනොත්? අන්න එවෙලාවට virtual machine එකක් මගින් execute වෙනවා නම් ලොවෙත් නැහැ. (virtual machine වර්චස් machine වෙන අවස්ථා නැතුවම නැහැ :D :D resources මරනවනේ, programmer ගේ අතේ සෑහෙන්න වැඩකොටසක් තියෙනවා resources අඩුව්න්ම කන විදිහට වග බලාගන්න)

Android, Dalvic Virtual Machine Linux

Android Run වෙන්නේ Linux මත android වලත් JVM එකට සමාන Virtual Machine එකක් දාල තියෙනවා Dalvic VM කියලා Linux උඩට. අපි android App එකක් හැදුවම ඒක SDK එකෙන් Java byte code එකට පත් කරලා එක Dex Compiler එකෙන් Dalvic Byte code බවට පත්කරලා තමා apk file ඇතුලේ store කරන්නේ. Android 4.4 වෙනකම් Android app JIT විදිහට Dalvic VM තමා execute කරේ. ඉතින් මේකට සැහෙන්න resources ඕන උනා පොඩි RAM තියෙන phone වල පාවිච්චි කරන්න ටිකක් අමාරු උනා. නමුත් 5.0 එක්ක Android Run Time environment  එක සමග Ahead Of Time compilation හඳුන්වලා දුන්නා එකේදී Android App වල තියෙන Dalvic Byte code, App එක install කරන වෙලාවේම Dalvic VM එක බාවිත කරලා Native code බවට පත් කරලා device එකේ .oat file එකක් විදිහට store කරලා ඒක බාවිතා කිරීම නිසා Android App වේගයෙන් execute වුනා නමුත් install වෙන්න වැඩි වෙලාවක් ගත උනා, නමුත් android 7.0 එක්ක ART සඳහා JIT හඳුන්වලා දුන්නා එකෙන් install වෙන්න ගතවෙන කාලය අඩු උනා.
එතකොට android app dalvic byte code වලින් තියෙන්න හේතුව Android තියෙන්නේ limited devices කිහිපයකට නෙවෙයි devices ගොඩක් තියෙනවා processor architectures ගොඩක් තියෙනවා, එහෙම නැතුව කෙලින්ම compile කරන්න ගියානම් Application Developer ඔය තියෙන හැම architecture එකකටම වෙන වෙනම compile කරන්න වෙනවා, ඒක අසාර්ථක අසීරු තේරුමක් නැති වැඩක්.

Root Linux Android

සරලව පැහැදිලි කරනවා නම් Linux ඇතුලාන්තයේ ඉඳන්ම multi-user සිංහලෙන් නම් බහු පරිශීලක පහසුකම් තියෙන පද්දතියක්, ඉතින් මේ පද්දතියේ user-account හදන්න පුළුවන් හිටු කියලා ඒ වගේම ඒ හදපු user account වලට පද්දතියේ මොන මොන දේවල්ද හසුරවන්න අවසර තියෙන්නේ කියන එක කියලා දෙන්න පුළුවන්, එතකොට ඒවා අර දුන්න අවසරයන්ට පිට කිසි සේත්ම වැඩ කරන්නේ නැහැ, එහෙම වැඩ කරනවානම් එදාට Facebook, Google වැනි සමාගම් වල මළගම සනිටුහන් කරන දවස වේවි,  ඉතින් Android වල මං දැකපු දෙයක් තමයි app එකක් install කරනකොටම ඒ app එක වෙනුවෙන් Linux user account එකක් හදලා දෙන එක ඊට පස්සේ ඒ user account ටික group එකකට හෝ කිහිපයකට ඇතුලත් කරනවා, උදාහරණයක් විදිහට sdcard_r කියන group එකට ඇතුලත් වුනු සියලුම user accounts වලට හැකියාවක් තියෙනවා External Memory එකේ data ලියන්න කියවන්න, තවත් සරලව පැහැදිලි කරනවා නම් ඔයා install කරා xxx කියන app එකක් ඒ app එකට a650 කියල linux user account එකක් හදුනා, මේ user account එක sdcard_r කියන group එකේ නැත්තම් එයාට බැහැ External Memory එකේ data ලියන්න. අනිත් එක මං කිඋවා android වල හැම app එකක්ම වෙන වෙන user account වල තියෙන්නේ කියලා, Linux permissions හදලා තියෙනවා ඒ ඒ user ට වෙන users ලගේ directory වලට access කරන්න බැරි විදිහට, එකිඋවේ එක app එකකට බැහැ තව app එකක folder එක ඇතුලේ data වෙනස් කරන්න. ඉතින් මේ වගේ ගොඩාක් බාදක දාල තියෙනවා Security එක වෙනුවෙන්. හැබැයි Linux වල ඉන්නවා කිසිම බාදාවක් නැතුව සම්පූර්ණ පද්දතියේම ඕනෑම තැනක data ලියන්න කියවන්න පුළුවන් user කෙනෙක්. මෙයාට system එකේ නීති රීති රෙගුලාසි කින්ද මන්ද බයිලා මොකුත් අදාළ නැහැ මෙයාට පුළුවන් පද්දතියේ ඕනෑම තැනක දත්ත ලියන්න කියවන්න. ඉතින් GNU Linux වල user account අතරේ මාරුවෙන්න binary වලින් එලෙක්ට්‍රොනික බාෂාවෙන් ලියපු executable එකක්(මොකක් හරි software එකක් කියලා හිතාගන්නකෝ) තියෙනවා, මේ executable එක පාවිච්චි කරලා තමයි Linux වල users අතරේ මාරුවෙන්නේ, සරලව පැහැදිලි කරනවා නම් ඔයාගේ Linux computer එකේ Amara සහ Kamal කියලා users ලා දෙන්නෙක් ඉන්නවා දැන් අමර එයාගේ account එකෙන් computer එකේ log වෙලා ඉන්නවා, මෙයාට හදිස්සියේ උවමනාවෙනවා කමල් ගෙ account එකෙන් log වෙන්න, අමර ඒක කරගන්න Linux පද්දතියට විධාන කරනවා "su kamal" එතකොට දැන් අමර කමල් විදිහට ලොග් වෙලා කමල් ගේ browser history එක බලනවා email කියවනවා හරි කැත වැඩ ඕවා... ඒ පාර අමර දැක්කා කමල් මොකද්ද GB 2 ක 3ක movie එකක් download කරලා තියෙනවා, අමර movie එක බලන්න උත්සහ කරනකොට mp4 play කරන්න computer එකේ Player එකක් නැහැ, දැන් අමර පද්දතියට විධාන කරනවා apt-get install vlc කියලා එතකොට Linux එකෙන් කියනවා "VLC install කරන්න අවසර නැහැ කියල " මොනවද කරන්නේ අවසර තියෙන user කෙනෙක්ට මාරුවෙන්න ඕන ඒකට පද්දතියට විධාන කරනවා su root කියල,  දැන් අමර root user ට මාරුවෙලා ඉන්නේ, මං කලින් කිඋවා root user ට තියෙනවා System එකේ හැම තැනම දත්ත ලියන්න කියවන්න අවසර තියෙනවා කියලා. ඉතින් අර users අතරේ මාරුවෙන්න හැකියාව දීල තියෙන su binary එක Android Linux වල එන්නේ නැහැ root කරනවා කියලා කට්ටිය කරන්නේ මේ binary එක අදාළ path එකට copy කරන එක තමා, ඉතින් මේ දේ කරන්න බැහැ System එකට log වෙලා ඉන්නකොට මොකද සියලුම නීති රීති කොන්දේසි වලට යටත් වෙලයි System එක on වෙලා තියෙන්නේ, හැබැයි පිට system එකකින් access කරද්දී මේ බයිලා මොකුත් අදාළ නැහැ. ඉතින් recovery එක කියන්නෙත් වෙනම operating system එකක් ඒකයි recovery එකෙන් ගිහිල්ලා කට්ටිය su සහ අදාළ files ඇතුලත් zip එක unzip කරන්නේ. හැබැයි එක දෙයක් system partition එක encrypt කරලා තිබ්බොත් මේ දේ recovery එකෙන් කරන එක ටිකක් අමාරුයි බැරිම නැහැ, ඉතින් මේ su binary එක අතින් copy කරන එක හැමෝටම කරන්න බැරි නිසයි rooting tools කියලා එක එක tools හැට හුටාමාරක් තියෙන්නේ.

Java Byte Code, Interpreter and JIT

සාමන්යෙන් program එකක් intermediate ආකාරයට compile කරලා ඒක virtual machine එකකින් interpret (අර්ථ වින්‍යාස කරොත් / පහදලා දුන්නොත්) ඒක කෙලින්ම executable code එකට compile කරලා run කරනවට වඩා. මන්දගාමී වෙනවා. 
කෙසේ වෙතත් Java සමග මේ දෙකේ වෙනස සාමාන්‍ය අවශ්‍යතා සඳහා එතරම් වැදගත් වෙන්නේ නැහැ. මොකද byte code හොඳට optimize කරලයි තියෙන්නේ. එනිසා අපි හිතනවට වඩා වේගයෙන් byte code execute වෙනවා.
Java නිර්මාණය කරලා තියෙන්නේ Interpreted language එකක් විදිහට, ඉතින් Java ළඟ මොකුත් නැහැ, වේගය වැඩි කිරීම සඳහා byte code, native code බවට පත්කිරීමේ on the fly compilation එක නතර කරන්න, 
මේ හේතුව නිසා HotSpot තාක්ෂණය හඳුන්වලා දුන්නා Java හි ප්‍රථම එළිදක්මෙන් පසු ඉක්මනින්ම. ඉතින් මේ HotSpot තාක්ෂණය මගින් byte code සඳහා Just in time (JIT) compiler එක සපයනවා. JIT compiler එකත් JVM එකේම කොටසක් ඉතින් මේකෙන් කරන්නේ තෝරාගත් byte code අවශ්‍යතාවයන්ට අනුව කොටස්, කොටස් වශයෙන් real time binary බවට පත් කරණ එක(ඒ කියන්නේ program එක run කරණ අවස්ථාවේ), අපි සැලකිලිමත් ව තේරුම් ගත යුතු දෙයක් තමයි Java, program එකක් සම්පූර්ණයෙන්ම compile කිරීම ප්‍රයෝගික නැහැ කියන එක. මොකද Java මගින් විවිද run time පරීක්ෂාවන් සිදු කරනවා, ඉතින් ඒවා කරන්න පුළුවන්නේ run time එකේදී විතරයි,
ඒ වෙනුවෙන් තමා JIT compiler එක අවශ්‍යතාවයන්ට අනුව, සම්පූර්ණ program එක නෙවෙයි අවශ්‍ය කොටස් ධාවන අවස්තාවේදී compile  කරන්නේ, ඉතුරු byte code සාමාන්‍ය ආකාරයට interpret  කරනවා. ඕක තමා JIT එකෙන් ලැබෙන ප්‍රයෝජනය. 
කෙසේ වෙතත්  JIT එක මගින් performance සදහා වැදගත් මෙහෙයක් ඉටුවෙනවා. 
byte code සඳහා dynamic compilation (JIT) භාවිත උනත් portability එක සහ safety features (JIT කරපු)ඒවටත් අදාළ වෙනවා. මොකද execution කාර්ය කරන්නේ JVM එක නිසා.
* Interpreter මගින් කරන්නේ line by line machine code එකට පරිවර්තනය කරණ එක 
* JIT මගින් කරන්නේ කොටස් වශයෙන් machine code එකට පරිවර්තනය කරණ එක 
ඉතින් JIT වේගවත් ධාවන අවස්ථාවේදී එකින් එක Translate කරන්නේ නැතුව අවශ්‍ය කොටසම compile කරණ නිසා.

එකම Public IP එක ISP කිහිප දෙනෙකුට ලබාදෙනවාද?

ඔව් එකම Public IP එක ISP කිහිප දෙනෙකුට assign කරනවා. ලංකාවේ නම් හැම ප්‍රසිද්ද සමාගමක්ම ඕක කරනවා. මේක හඳුන්වන්නේ NAT444 LSN / CGN කියලා Carrier Grade NAT / Large Scale Network Address Translation , ඔවුන් එසේ කරන්නේ ඔවුන් සතු සීමිත IP ප්‍රමාණයක් පමණක් තිබෙන නිසා. එතකොට ඔවුන් ඔවුන්ගේ පාරිභෝගිකයන් අතර privet network එකක් හදලා ඒක public ipv4 address එකකට / හෝ කිහිපයකට translate කරනවා middlebox address translator එකෙන්. එතකොට මෙතැනදී ඕනෑම NAT එකක දී සිදුවෙන end to end principal එක break වෙනවා ඒ නිසයි අපේ computer එකේ පෙන්වන ip එකයි site එකකට ගිහිල්ල check කරාම වෙන IP එකක් පෙන්වන්නේ .

 එතකොට අපේ public ip එක ඔස්සේ වෙන කෙනෙක්ට අපිත් එක්ක සම්බන්දවෙන්න වෙන්න පුළුවන් හැකියාව නැතිව යනවා. ඒ වගේම මෙවැනි Network එකක reliability සහ scalability ගැටළු මතුවෙනවා. 
මුලදී SLT ලා උනත් dynamic IP ලබා දෙනකොට සියල්ලන්ටම අවස්ථානුකූලව unique IPs ලබා දුන්න නමුත් දැන් පාරිබෝගිකයින් වැඩි නිසා ඔවුනුත් CGN කරනවා, මොකද ඔවුන් සතු IP ප්‍රමාණය සීමිත නිසා, නමුත් ඉල්ලීමක් කලොත් ඔවුන් CGN එකෙන් ඔබව අයින් කරනවා. Etisalat සහ අනෙකුත් සියලුම mobile network operators CGN එකක් හරහාම විතරයි ඔබව සම්බන්ද කරන්නේ, ඔබට අවශ්‍ය නම් පමණක් static IP එකක් මිලදී ගැනීමට හැකියාව තියෙනවා, (ලංකාවේ සාමාන්‍ය IP එකක මිල රුපියල් 1500ක් විතර) එතකොට ඔබ පරිවර්තනය කරන ලද ජාලයකට සම්බන්දවෙන්නේ නැහැ, එතකොට ඔබට end to end සම්බන්දතා පවත්වාගන්න පුළුවන් තවත් සරලව කිඋවොත් ඔබට අන්තර්ජාලයට විවුර්ත උන server එකක් පවත්වාගන්න පුළුවන්. CGN එකකදී ඔබ සම්බන්දවී සිටින ජාලයේම පරිගණක අතර ඔබට සම්බදතා පවත්වාගන්න හැකියාව තියෙනවා සරලව කිඋවොත් ඔබව පරිවර්තනයට ලක් කොට තිබුනත් ඔබට SLT සහ Etisalat ජාලවලදී අනෙක් පාරිබෝගිකයන් සමග ip එක හරහා ඍජු සම්බන්දතා පවත්වාගන්න පුළුවන්, නමුත් පාහේ අනෙකුත් සියලුම mobile network operators ලා ජාලය තුල ඍජු සම්බන්දතා පවත්වන්න පුළුවන් හැකියාවත් block කරලා තියෙන්නේ. dialog 4g වැනි සම්බන්දතා වල ඔබ ඉල්ලීමක් කලොත් ඔබව CGN එකෙන් අයින් කරනවා ඒකට මං හිතන්නේ මාසිකව 150ක් වගේ ගෙවන්න ඕන(නිවැරදි නොවෙන්න පුළුවන්)
ලංකාබෙල් නම් දැනට සියලුම dynamic ip හිමිවන පාරිබෝගිකයින්ට දෙන්නේ unique public ip එකක් ඉදිරියේදී ඔවුනුත් පාරිබෝගිකයන් වැඩි වෙනකොට IP ප්‍රමාණය සීමිත වෙනකොට CGN/LSN ක්‍රමයට මාරු වෙන්න පුළුවන් 
මේ ඔක්කොටම හේතුව ලෝකයේ ලෝකයේ ipv4 ලිපින සියල්ල විකුණා හමාර වීමයි ARIN සතුව තව ඇත්තේ IP blocks කිහිපයක් පමණි. ip4 බාවිතකරන්නේ 32bit 2 තිස් දෙවෙනි බලයයි එනම් theoretically උපරිම IP ප්‍රමාණය - 4,294,967,296 .
මෙයට විසඳුමක් ලෙසයි 128bit ip හඳුන්වා දුන්නේ ipv6 . ipv6 සතු ip ප්‍රමාණය කොතරම් ද යත් අවශ්‍ය නම් ලෝකයේ වෙසෙන සතා සිවුපාවන්ට වූවද IP ලිපින ලබාදීමට හැකියාව ඇත.
ඔබ CGN ජාලයක සම්බන්ද වෙලා හිටියත් අපිට අතර මැදි server එකක් හරහා ලෝකයට අපේ පරිගණකය Network Tunneling සිදුකර  විවුර්ත කිරීමේ හැකියාව තියෙනවා. උදාහරහණයක් විදිහට ඔයාට පුළුවන් Google Cloud Compute Engine, Amazon EC2 instance වැනි හෝ වෙනත් ඕනෑම Linux  VPS / Dedicated Server එකක් මාර්ගයෙන් Tunneling සිදු කිරීමට, එතකොට ඔබේ පරිගණකයේ IP ලිපිනය ලෙස අර VPS එකේ IP එක හැසිරෙනවා ඔයාගේ ගෙදර Linux machine එකේ තියෙන web / voip / game server එකට තවත් කෙනෙකුට VPS එකේ IP එක පාවිච්චි කරලා කෙලින්ම accesses කරන්න පුළුවන්, . අපි ඉස්සරහට තවත් ලිපියකින් බලමු කොහොමද ලෝකයේ තැන් දෙකක තියෙන Public IP එකක් සහ CGN IP එකක් තියෙන Linux machine දෙකක් අතර tunneling කරන්නේ කියල. 
ඒ වගේම Etisalat, SLT CGN/LSN ජාලවල ඉඳලා ජාලයේම තවත් user කෙනෙක් එක්ක IP එක හරහා file transfer කරගන්නේ කොහොමද කියලා.

KIM සමග Kingswood අපි

එහෙ මෙහෙ දුව පැන
විඩා නොසලකා
අපේ දහඩිය, සුසුමෙන්
අපවම ප්‍රාණවත් කළ
අපේ ආදරණීය "කිංස්වුඩ් ඉස්ලාම් මජ්ලිසය"
කෙටියෙන්ම කියනවානම් KIM....

වෙන්ව යන්නට තව නොබෝ කාලයයි
සිත පුරා දුක ඉරිතලයි
විදු මවට සේම KIM වෙතද

අපේ ප්‍රණාමය පුදකරන්න අවසරයි...
සිසු දිවියේ කඩ ඉමට
අරුතක් එක් කරන්නට
අපට ඉඩහසර දුන්
අපේ සෙනෙහෙබර KIM

අපි ඔබට ණයගැතියි
ලස්සනට සැරසූ
බ්ලසේ ශාලාවේ
වාද විවාද, කථික ක්රාත්
තවත් සුවහසක් තරඟ තුර
ජය පරාජය දෝතින්ම ගෙන
විඳ දරාගන්නට සවිය දුන්
KIM සදා අනුස්මරනීයයි...

අපේ නියමුවාණන් විදුහල්පති තුමන්
සිප් කිරි පෙවූ ගුරු මාපියන්
Kingswood සම්ප්‍රදායෙන්ම අපේ වීරයන්
හැමදාමත් සිහි කරනවා බැතියෙන්.

ඕන හැම තැනකදීම
අපට ඔවදන් දී
දැනුමෙන් අප සවිමත් කළ
අපේම මවුලවි සර්....

සලාත්, සලවාත්, තිලාවත් සේම
කෙළි කවටකම් සිනා හඬ දෝන්කාරේ දෙන
නැටුම් ගැයුම් නිමක් නැති
ඉහිරුණු කොලු කමට ජීවය දුන්න
අපේම ඉස්ලාම් කාමරය....

තව නොබෝ දිනකින්ම
සමුගන්නවා අප සියල්ලෙන්
විදු බිම පුරාවට අපට සෙවන දුන්
ගහකොළ ද මල් ගල් වැටිද
විරහවෙන් රිදීවි - අපේ සිත් සේම
හඬනවා නියතයි......

වේදනාව දුක් දෝමනස්ස
අප මුහුණ දුන් නේක පීඩා
අපිම තියාගෙන
මල් ඵල ද කිත් පැසසුම්
ආදරයෙන් තිලිණ කරන්නම්
අපේම මල්ලිලාට
ස්නේහය පිරුණු සිතින්......

බැතියෙන්ම රැකගන්න
අපේ ආදර Kingswood විදු මව
ගුරු මවු වරුන් පියවරුන්
විදු බිමේ සසල නිසල සම්පත්
සියල්ලත් සමග

KIM ආදරයෙන්.....

නොනවතිනා ගමනකට
දිගාසිරි පතමු ඔබට
KIM අපේ ජීවයයි ඔබ

සොඳුරු සිත්තමක් වී
සදා මතකයේ සරණ......

ෂුජා රාෆි

2015 

KFE