သက္ကရာဇ်၂၀၂၁ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများ
Previousသက္ကရာဇ်၂၀၂၀ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများNextStorage အကြောင်းတစေ့တစောင်း – အပိုင်း(၁)
Last updated
Was this helpful?
Last updated
Was this helpful?
ပုံမှန်အားဖြင့် စာရေးသူ အခုလိုမျိုး နိုဝင်ဘာလ၊ ဒီဇင်ဘာလတွေမှာ စာတွေအများကြီးရေးဖြစ်လေ့ရှိပါတယ်။ ဒီနှစ် ၂၀၂၁ မှာတော့ စိတ်ရှုပ်စရာတွေ၊ စိတ်အားပျက်မှုတွေနဲ့ အတူတော်တော်လေးကို မွန်းကြပ်မှုတွေနဲ့ လုံးပန်းရလွန်းလို့ စိတ်အနားရတယ်လို့ကို မရှိပါဘူး။ ကိုယ်တိုင်မှာလည်း ဘဝရဲ့အဆစ်အချိုး အချိန်တွေကို အတိုင်းအတာတစ်ခုထိ ခက်ခက်ခဲခဲ ဖြတ်သန်းနေရလို့ အချိန်ပေးပြီးတော့ စာတွေထပ်ရေးဖို့ ပျင်းလာတာကလည်း ငြင်းလို့မရပါဘူး။ မည်သို့ပင်ဖြစ်စေကာမှု စာတွေဆက်ရေးဖို့ကတော့ အမြဲတန်းလိုလို တောက်လျှောက်မပျက် ခေါင်းထဲမှာရှိပါတယ်။ စာတွေလည်း အများကြီးထပ်ပြီးတော့ ရေးချင်နေသေးတာ အမှန်ပါ။ အခုလည်း ၂၀၂၁ ခုနှစ်က ဘယ်လိုကုန်လို့ ကုန်သွားမှန်းကို မသိလိုက်ဘူး။ သို့သော်နည်းပညာလောကထဲမှာ အဖြစ်အပျက်တွေက အများကြီးပဲလို့ စိတ်ထဲမှာ အမှတ်ရလို့ နှစ်မကုန်ခင် အရင်ချရေး ထားချင်သောကြောင့် ဒီ post ကိုရေးရခြင်း ဖြစ်ပါတယ်။ ပြီးခဲ့နှစ်ကတော့ ရေးဖို့ကို နှပ်ထားရင် အလုပ်များတာနဲ့ စစ်တပ်အာဏာသိမ်းသွားနဲ့ ပေါင်းပြီး တော်တော်လေးနောက်ကျမှကို အပြီးသတ်နိုင်ပါတယ်။ ဒီနှစ်အတွက်တော့ ကြိုပြီးတော့ရေးထားဖို့ စာရေးသူပြင်ဆင် မှင်တို့ထားရပါတော့သည်။
(၁) Linux kernel နှစ်သုံးဆယ်ပြည့်
ဒီနှစ် ၂၀၂၁ခုနှစ်မှာတော့ Linux kernel ဟာ နှစ် ၃၀ တင်းတင်းပြည့်ပါပြီ။ တချိန်က University of Helsinki ကနေ စတင်လိုက်တဲ့ hobby project တစ်ခုဟာ အခုဆိုရင် နေရာတကာမှာအသုံးများနေတဲ့ OS kernel တစ်ခုအနေနဲ့ နှစ်သုံးဆယ်ပြည့်လို့လာပါတယ်။ Linux kernel စတင်လိုက်ကတည်းကနေ အခုအချိန်ထိ ပြောင်းလဲတိုးတက်လာတွေလည်း open-source ကမ္ဘာမှာအခုဆိုရင် မရေတွက်နိုင်အောင်ပဲများလွန်းလှပါတယ်။ သစ်တပင်ကောင်းတော့ ငှက်တသောင်းနား နိုင်စေတာလို့ပဲ စာရေးသူမြင်မိပါတော့တယ်။ အရင်တုန်းကလည်း Linux kernel အကြောင်းကို အသေးစိတ်ရေးပြီးသားမို့ အများကြီးထပ်ပြီး စာမဖွဲ့ချင်ပါ။ Linux kernel နဲ့ ပတ်သတ်တဲ့ article တွေကိုဖတ်ချင်ရင် အောက်မှာပါတဲ့ လင့်တွေကနေသွားရောက်ဖတ်ရှုနိုင်ပါတယ်။
(၂) CentOS Clones နှစ်ခု စတင်ခြင်း
ပြီးခဲ့နှစ် ၂၀၂၀တုန်းကရေးတဲ့ထဲမှာ CentOS 8 ကို အခုနှစ် ၂၀၂၁ နှစ်ကုန်မှာ End Of Life (EOL) လုပ်ဖို့ RedHat ဘက်ကထုတ်ပြန်ပြီးတဲ့နောက်မှာ open-source နဲ့ Linux community တွေထဲမှာ တော်တော်လေးကို ဆူဆူလောင်လောင်ဖြစ်ခဲ့ရပါတယ်။ အချို့ကလည်း RedHat ရဲ့လုပ်ရပ်ကို လက်ခံပြီးတော့ ပြောင်းသင့်တဲ့အပြောင်းအလဲ တစ်ခုဖြစ်တယ်လို့ ဝေဖန်ပြောဆိုတာရှိခဲ့သလို၊ IBM က RHEL ကို ဝယ်ပြီးတဲ့နောက်ပိုင်း အကျိုးအမြတ်ပိုရနိုင်ဖို့အတွက် ရည်ရွယ်ချက်အပြည့်နဲ့ လုပ်တယ်လို့လည်း ဆိုလာသူတွေရှိပါတယ်။ စာရေးသူအမြင်က နှစ်ဘက်လုံးမှာ ကိုယ်ဆီသွားချင် Agenda တွေရှိနေတယ်လို့မြင်ပါတယ်။ ၂၀၂၁ခုနှစ်ထဲမှာ တဖြည်းဖြည်းနဲ့ နားလည်လာတာတစ်ခုက လူတိုင်း တယောက်ချင်းစီမှာပဲဖြစ်ဖြစ်၊ အုပ်စုလိုက်ဖွဲ့ စည်းထားတဲ့ အသင်းအဖွဲ့တွေမှာပဲဖြစ်ဖြစ်၊ ပြောတဲ့စကားတိုင်း လုပ်တဲ့လုပ်ရပ်တိုင်းမှာ Agenda ဆိုတဲ့ ဦးတည်ချက်လားရာအမြဲတွဲပြီး ပါလေ့ရှိပါတယ်။ အတ္တတွေနဲ့မို့ ဘယ်သူမှ မရိုးခဲ့ကြပါဘူး။ စာရေးသူလည်း အဲ့ဒီထဲမှာပါတယ်။ အဲ့ဒီကိစ္စကို ဒီနေရာမှာနည်းနည်းလေး ထည့်ပြီး ဆွေးနွေးကြည့်ရအောင်။
CentOS ကို RedHat ကစပြီးတော့ sponsor လုပ်ကတည်း ရည်ရွယ်ချက်နှစ်ခုရှိတယ်လို့ ယူဆရပါတယ်။ ပထမတစ်ခုက community ထဲမှာ RHEL ရဲ့ stable clone ကို ဒီအတိုင်းထားမယ့်အစား influence လုပ်လို့ရနိုင်တဲ့ လက်တချောင်းလိုပါတယ်။ နောက်တချက်က RHEL ရဲ့ Software Development Life Cycle (SDLC) ထဲမှာ တနည်းနည်းနဲ့ထည့်သုံးရနိုင်အောင်လည်း ကြံရွယ်ပုံရတယ်။ RedHat လို profitable ဖြစ်တဲ့ company တစ်ခုက CentOS ကို sponsor လုပ်ခြင်းဖြင့်လည်း open-source community ထဲမှာ သြဇာလည်းတက်၊ နာမည်လည်းရမယ့်ဟာကို ကြိုမြင်ပုံရပါတယ်။ အဲ့ဒီအတိုင်းပဲ လူတိုင်းရဲ့ ယုံကြည်မှုကို RedHat ကအပိုင်ရယူနိုင်ခဲ့တယ်။ အားလုံးအတွက် win-win situation တစ်ခုကို ဖန်တီးလိုက်နိုင်တဲ့ sponsorship အနုပညာတရပ်လို့တောင်ဆိုလို့ရမလားမသိဘူး။ ဒီလိုနဲ့ CentOS ဟာ RHEL ရဲ့ downstream project ဖြစ်လို့လာပြီး၊ RedHat မျှော်လင့်ထားသလို CentOS ကနေပြီး feedback ကောင်းကောင်းပြန်လာတာမျိုး မရှိသလောက်ရှားပါးတဲ့အတွက် RHEL အတွက်အများကြီး အထောက်အကူ ပြုသင့်သလောကမပြုခဲ့ပါဘူး။ သို့သော် အားလုံးထဲမှာ အမြတ်ထွက်သွားတာက web hosting company ကြီးတွေနဲ့ enterprise အကြီးစားတွေမှာ RHEL ကို ငွေကုန်ခံပြီးတော့ အသုံးပြုမယ့်အစား CentOS လိုမျိုး RHEL ရဲ့ clone ကိုသာ တွင်တွင်ကျယ်ကျယ်အသုံးပြုလို့လာခဲ့ကြတယ်။ RedHat ဘက်မှာတော့ ပိုပြီးတော့အလုပ်ဖြစ်လာမလို့ ဆိုပြီးတော့ sponsor လုပ်လိုက်တာဖြင့် သူ့ရဲ့ရောင်းအားကိုပါလာထိတဲ့ သဘောမျိုးဖြစ်နေတယ်လေ။ IBM က RedHat ကိုဝယ်ပြီးတဲ့နောက်မှာတော့ ဒီကိစ္စဟာ အမြတ်အစွန်းထွက်ဖို့အတွက် ကျော်သွားလို့မရတဲ့ အနေအထားမျိုးဖြစ်လာပါတယ်။ အဲ့ဒီအတွက် CentOS ကို RHEL ရဲ့ downstream မှာမထားတော့ပဲ၊ upstream မှာထားလိုက်ခြင်းအားဖြင့် တချက်ခုတ် သုံးလေးငါးချက်ပျက် သလိုဖြစ်နေတဲ့အတွက် CentOS 8 မှာပဲ EOL ကိုအမြန်ဆုံးရောက်အောင် ကိစ္စရှင်းတဲ့ပုံစံမျိုးပါ။ RHEL လောက် stable မဖြစ်ပေမယ့်လည်း ဆက်သုံးချင်သုံးလို့ ရအောင်တော့ CentOS stream ကို rolling release အနေနဲ့ ထားရစ်ခဲ့ပေးပါတယ်။ Upstream ဖြစ်လာတဲ့ အတွက် feedback loop လည်း RHEL အတွက်ပိုကောင်းဖို့ပဲရှိပါတယ်။ ဒီအတွက် ရလဒ်ကတော့ အထက်မှာပြောခဲ့တဲ့ hosting company တွေနဲ့၊ အချို့သော အရမ်းကို ချမ်းသာတဲ့ company တွေ enterprise တွေ မှာ CentOS 8 ရဲ့ EOL ကိုဖြေရှင်းဖို့အတွက် Ubuntu လိုမျိုး Debian based distro တွေဆီကိုပြောင်းနည်းတစ်ခု၊ OpenSUSE လိုမျိုး RPM သုံးတဲ့ distro ကိုပြောင်းနည်းကတဖုံ အမျိုးမျိုးကြံဆရပါတော့တယ်။ အံ့သြဖို့ကောင်းတာက CentOS ကို အသုံးပြုနေတဲ့ company တွေထဲမှာ Tesla တို့လိုမျိုး အချမ်းဆုံးသော company တွေပါဝင်နေတယ်ဆိုတာပါပဲ။ နောက်ဆုံး အဲ့ဒီအဖြစ်အပျက်တွေကြားကနေ CloudLinux နဲ့ Rocky Linux နှစ်ခုကနေ CentOS community တစ်ခုလုံးအတွက် ကတိကဝတ်ပြုပြီး RHEL ကို clone လုပ်ပြီးမှ maintain လုပ်ဖို့ကို အရင်နှစ် ၂၀၂၀ ကုန်ခါနီးမှာ သတင်းထွက်လာပါတယ်။ အောက်မှာတော့ CloudLinux ကထုတ်တဲ့ AlmaLinux distribution နဲ့ Rocky Linux နှစ်ခုကို download လုပ်ဖို့ရာ လင့်တွေကိုထည့်ပေးလိုက်ပါတယ်။
(၃) Hypocrite commits တွေနဲ့ Linux kernel
Linux kernel ဟာ open-source ဖြစ်တဲ့အတွက် ဘယ်သူမဆိုဝင်ပြီးတော့ ပြင်လို့ရတယ်၊ pull request လုပ်လို့ရပါတယ်။ အဲ့လိုမျိုး လုပ်လို့ရတဲ့ trusted network ထဲမှာ အချို့သော company တွေနဲ့ university တွေပါတယ်။ ဒီလို trusted network ထဲမှာပါဖို့၊ ဖြစ်လာဖို့ ဆိုတာမျိုးဟာကလည်း pull request တော်တော်များများနဲ့ ဝင်ပြီးတော့ contribute လုပ်ထားမှရလာတဲ့ status တစ်ခုဖြစ်တယ်။ ကိုယ်ပြင်ချင်တိုင်း ဝင်ပြင်၊ ဝင်ပြီး pull request လုပ်လို့ဆိုတာလည်း လွယ်တဲ့ကိစ္စတော့လည်း မဟုတ်ပါဘူး။ ဒီနှစ်ထဲမှာ ထူးခြားတာတစ်ခုက University of Minnesota (UMN) မှာ research လုပ်နေတဲ့ ကျောင်းသားအဖွဲ့တစ်ခုကနေပြီး Linux kernel မှာဘယ်လိုမျိုး flaw တွေရှိနိုင်တယ်ဆိုတာကို research လုပ်တဲ့ဟာမှာ ဖော်ပြချင်တဲ့အတွက် Hypocrite Commits ဆိုပြီးတော့ malicious code တွေကိုထည့်သွင်းပြီး pull request/merge request လုပ်ခဲ့ပါတယ်။ ဒါကို Linux kernel ရဲ့ gatekeeper လို့တောင်တင်စားပြီးတော့ ခေါ်ကြတဲ့ Greg Kroah-Hartman က review လုပ်တဲ့အခါမှာ တွေ့ရာကနေ ပြဿနာကစပါတော့တယ်။ အဲ့ဒီကစလို့ University of Minnesota (UMN) ကအရင်တုန်းက တင်ခဲ့တဲ့ commits တွေကိုပါပြန်ပြီး မြေလှန်ရှာပါတော့တယ်။ အစဉ်အလာ အားဖြင့်တော့ UMN က reputation ကောင်းတဲ့ contributor တစ်ခုပါ။ အခုတော့ research ကျောင်းသားတွေလုပ်လို့ Linux Foundation ရဲ့ Technical Advisory Board (TAB) နဲ့ အခြားသော Linux kernel developers တွေက UMN ကို ဆက်ပြီးတော့ commits တွေပေးမတင်တော့ပါဘူး။ ၂၀၂၁ ခုနှစ်မှာတော့ open-source community တစ်ခုလုံးကို တုန်ခါသွားစေတဲ့ သတင်းတစ်ခုဖြစ်ခဲ့ပါတယ်။ ဒါ့အပြင် Linux kernel ကို open-source လုပ်ပြီးတော့ commits တွေကို ဘယ်လို handle လုပ်တယ်၊ ဘယ်လို review လုပ်တယ်ဆိုတာကိုကလည်း စာရေးသူတို့ စိတ်ဝင်စားစရာ လေ့လာသင်ယူရပါတော့တယ်။
(၄) SolarWinds Stock Market မြင့်တက်မှု
SolarWinds ရဲ့ ခုနှစ် ၂၀၂၀ ဟာရုပ်ဆိုးစွာဖြင့်ပြီးဆုံးခဲ့ရပြီးတော့၊ နည်းပညာ company တွေတော်တော်များများလည်း SolarWinds ရဲ့ breach ကြောင့်တော်တော်လေး အလုပ်ရှုပ်သွားစေခဲ့ပါတယ်။ အပြင်ပိုင်းကြည့်လိုက်ဖြင့် SolarWinds ရဲ့အနာဂတ်ဟာ အတော်ကို အကြည်တန်ရုပ်ဆိုးစေနိုင်တာကိုတွေ့ရမှာပါ။ သို့သော်လည်း ဒီနှစ် ၂၀၂၁ ခုနှစ်မှာတော့ SolarWinds ရဲ့ stock market ဟာအတက်ဘက်ကို ပြန်လို့တောင်ရောက်လာတာကိုတွေ့ရမှာပါ။ SolarWinds ရဲ့ products တွေကိုသုံးတဲ့ company တွေအနေနဲ့လည်း network monitoring platform တစ်ခုလုံးကို အကုန်ဖြုတ်ပြီး ရှိသမျှဟာတွေကို အခြားသော product တစ်ခုနဲ့ပြန်ပြီး စဖို့ဆိုတာ နည်းနည်းတော့လည်း မလွယ်ပါဘူး။ အဲ့ဒီတော့ ဖြစ်လာပုံက SolarWinds ရဲ့ support နဲ့ developer တွေကိုငွေကြေးပိုပေးပြီး ဒီထက်လုံခြုံအောင်သာ လုပ်ပေးဖို့ ညှိကြပုံရပါတယ်။ SolarWinds ကထုတ်တဲ့ product တွေဟာလည်း network monitoring အတွက် အတော်ကိုအသုံးများရုံသာမက၊ နည်းပညာနယ်ပယ်ထဲကလူတွေ အတော်လေးကို ကြိုက်နှစ်သက်ကြပါတယ်။ အဲ့ဒီအတွက်လည်း customer တွေအများကြီးတိုးပြီးတော့ ရလာတာမျိုးထက်၊ support ကိုစျေးမြင့်တင်ခြင်းဖြင့် ပိုပြီး profitable ဖြစ်စေတဲ့ stock တစ်ခုအနေနဲ့ ရပ်တည်လာပုံရပါတယ်။ သို့သော်လည်း အရင်တုန်းကလောက် stock စျေးပြန်မတက်လာပါဘူး။ ဒီနေရာမှာ စိတ်ဝင်စားစရာတစ်ခုက publicity တိုင်းဟာကောင်းပါတယ်။ Bad publicity ဖြစ်သည့်တိုင်အောင် လူတွေရဲ့စိတ်ဝင်စားခြင်းခံရသဖြင့် company အတွက်ပိုလို့တောင်ကောင်းတယ်လို့ ဆိုနိုင်ပါတယ်။ COVID-19 စစချင်းတုန်းက Zoom ဟာလည်း bad publicity အချို့နဲ့စတင်ခဲ့ရာကနေ အခုဆိုရင် ဘယ်သူမဆို Zoom ကိုမကြားဘူးတဲ့သူ မရှိသလောက်ပါပဲ။
(၅) Ingenuity Landing နဲ့ Linux ရဲ့အောင်ပွဲ
Linux ကမ္ဘာမှာနောက်တစ်ခု စိတ်လှုပ်ရှားစရာ နောက်တစ်ခုက Ingenuity Helicopter ဟာ ကမ္ဘာနဲ့ လေထုသိပ်သည်းဆ မတူတဲ့ Mars မှာအောင်မြင်စွာ ဆင်းသက်နိုင်ခဲ့ပါတယ်။ မှတ်မှတ်ရရ အဲ့ဒီ NASA project ကိုဦးဆောင်တဲ့ အမျိုးသမီးဟာ စာရေးသူတို့ မြန်မာလူမျိုးဖြစ်နေတဲ့အတွက် ပိုလို့တောင် ဂုဏ်ယူမိပါသေးတယ်။ ကိုယ့်မြန်မာလူမျိုး မညံ့တာကို ဒီနေရာမှာအသိအမှတ်ပြုရမှာပါ။ လက်ရှိဖြစ်နေတဲ့ စစ်တပ်အာဏာသိမ်းပြီးတော့ မတရားလုပ်နေတာကို မြင်တိုင်းကြားတိုင်း စာရေးသူတို့အတွက် တန်ဖိုးရှိလှတဲ့ လူ့အရင်းအမြစ်နဲ့ အချိန်တွေအရမ်းကို ကုန်ရပါလားလို့ တွေးမိတိုင်းလည်း ဒေါတအလိပ်လိုက် ထွက်မိတာအမှန်ပါ။ ဒါကိုလည်း လူထုတရပ်လုံး နားလည်လို့ အခုလိုမျိုးမတရားလုပ်နေတဲ့ စစ်တပ်ကို ဒီပွဲမှာအပြတ်ဖြုတ်နေတယ်လို့တော့ထင်ပါတယ်။ ပေးသလောက်လည်း အကုန်ပြန်ရရမယ်လို့ စာရေးသူ ယုံကြည်တယ်။
ဆိုလိုရင်းဖြစ်တဲ့ Linux kernel အကြောင်းပြန်သွားလိုက်ရအောင်။ NASA ရဲ့ Ingenuity Helicopter ကိုအောင်မြင်စွာ landing လုပ်နိုင်အောင် စွမ်းဆောင်ပေးတာ စာရေးသူတို့ မြန်မာလူမျိုး အမျိုးသမီး ရဲ့ဦးဆောင်မှုအပြင်၊ နောက်ထူးခြားချက်က Linux kernel ကလည်းတိုက်ရိုက်ပါဝင်ပတ်သတ်နေပါတော့တယ်။ Ingenuity ကို အဝေးကနေထိန်းဖို့အတွက် အသုံးပြုတဲ့ custom OS ဟာ Linux kernel ကိုအသုံးပြုထားတဲ့အတွက် power consuming ရော၊ operation အတွက် reliability မှာပါအကုန်အဆင်ပြေပြေ ပျံသန်းနိုင်အောင် ကူညီထောက်ပံ့ပေးခဲ့ပါတော့တယ်။ ဒီိလိုနဲ့ Mars မှာ ပထမဆုံး အသုံးပြုတဲ့ OS တစ်ခုရဲ့ kernel အနေနဲ့ မှတ်တမ်းတင်နိုင်ခဲ့တယ်။
(၆) IPO ဖြစ်လာတဲ့ GitLab နဲ့ HashiCorp
Company တွေဟာ IPO ဖြစ်ဖို့အတွက် အချိန်ပေးရရုံသာမက၊ stock market ရဲ့လိုအပ်ချက်တွေကို အကုန်ကိုက်ညီအောင်လို့လုပ်ဖို့ရာအတွက် resource တွေအများကြီး ကုန်တဲ့ကိစ္စပါ။ IPO ဖြစ်လာတယ်ဆိုတာက အလွယ်ပြောရရင် company တစ်ခုရဲ့ stock တွေကို market မှာလူတိုင်း ဝယ်ယူလို့ရအောင် လုပ်တာမျိုးပါ။ ဒီအတွက် core investor တွေသာမကပဲ၊ stock holder တွေပါထပ်ပြီးတော့တိုးလာတဲ့ အတွက် company ဖို့ရာ funding မှာအများကြီးပိုလာတယ်။ ဒီအတွက် တိုးချဲ့လုပ်ဖို့ရာ လုပ်ငန်းစဉ်များအတွက် ငွေပိုရလာတဲ့ သဘောမျိုးပါ။ အခြားသော အကျိူးအမြတ်တွေလည်း များစွာရှိသော်လည်း စာရေးသူသေချာတော့ မသိတော့ပါ။
ဒီနှစ်ထဲမှာ GitLab နဲ့ HashiCorp နှစ်ခုလုံး IPO ဖြစ်လာပါတယ်။ Company နှစ်ခုလုံးက open-source ဖြစ်တဲ့အပြင်၊ developer တွေရဲ့ အသည်းစွဲ product များစွာထုတ်တဲ့ company နှစ်ခုပါ။ စာရေးသူ GitHub ကို public facing အတွက်အသုံးပြုများသော်လည်း၊ GitLab ကိုတော့ personal project တွေအတွက်အသုံးပြုတာများပါတယ်။ HashiCorp ဆိုတာကတော့ စာရေးသူ အသေကြွေရတဲ့ Vagrant တို့၊ Terraform တို့၊ Vault တို့လို Infrastructure As Code (IaC) toolchain တွေကိုထုတ်ပေးတဲ့ company ဖြစ်တဲ့အတွက် IPO ဖြစ်လာတာကို ဝမ်းမြောက်ဝမ်းသာ ဖြစ်ရပါတယ်။ Innovation ပိုင်းမှာတော့ နှစ်တိုင်း product အသစ်တွေအများကြီး ထုတ်နိုင်တဲ့ company နှစ်ခုပါ။
(၇) နှစ်ကုန်ခါနီးတိုင်း ဖြစ်တတ်လွန်းတဲ့ 0-day vulnerability
ပြီးခဲ့နှစ်က SolarWinds ရဲ့ supply-chain attack ကြောင့် ICT engineer တွေတော်တော်လေးကို အလုပ်ရှုပ်ခဲ့ကြရပါတယ်။ ဒီနှစ်မှာတော့ Log4Shell ဆိုတဲ့ zero day vulnerability တစ်ခုနှစ်ကုန်ခါနီးကြမှာ ထပေါ်လာပြန်ပါတယ်။ ပြီးခဲ့ တစ်ပတ်နှစ်ပတ်လောက်မှာ CVE-2021-44228 ဆိုတာ ထွက်လာပါတယ်။ Apache ကထုတ်တဲ့ Java application တော်တော်များများမှာ အသုံးပြုထားသော Log4j လို့လူသိများတဲ့ logging interface တစ်ခုပါ။ Java Naming and Directory Interface (JNDI) လို့လည်းလူသိများလာတဲ့ attack surface တစ်ခုပါ။ နည်းပညာလောကထဲက software နဲ့ hardware vendor တွေအများကြီး အဲ့ဒီ open-source logging interface လေးကိုအသုံးပြုတဲ့အတွက် နောက်ဆုံး အသစ်ထုတ်ထားတဲ့ version နှစ်ခုကလွဲလို့ log4j ကိုသုံးတဲ့ software တွေနဲ့ platform တွေအကုန် vulnerable ဖြစ်ပါတယ်။ နောက်ဆုံး version တစ်ခုမထွက်လာခင် စပ်ကြားမှာတော့ log4j ကို manually disable လုပ်လို့ရတယ်။ အဲ့ဒါကို hotfix သို့မဟုတ် patch အနေနဲ့ vendor တော်တော်များများက သူတို့ Security Advisory Board မှာတင်တာကိုတွေ့ရပါတယ်။ VMware လိုမျိုး virtualisation vendor မှာအများကြီး ထိပါတော့တယ်။ အခြားသော vendor တွေလည်း vulnerable ဖြစ်တဲ့ထဲမှာပါတယ်။ ဒီတော့ ဒီသတင်းထွက်လာပြီဆိုကတည်း vulnerable ဖြစ်နိုင်တဲ့ platform တွေကို bad actors တွေစတင်ပြီးတော့ scan လုပ်ပါတယ်။ အချို့လည်း အချိန်မှီ patch မလုပ်နိုင်တာပဲဖြစ်ဖြစ်၊ လုံးဝကိုမသိလိုက်တာပဲဖြစ်ဖြစ် Log4Shell vulnerability ကိုသုံးပြီးတော့ breach လုပ်ဖို့အကြောင်းဖန်လာပါတယ်။ ဒီနေရာမှာ စာရေးသူ အတည်ပြုလာနိုင်တာတစ်ခုကတော့ developer တွေဟာ security specialist တွေမဟုတ်ဘူးဆိုတာပဲဖြစ်ပါတယ်။
(၈) Open-source တစ်ခုတည်းကို သုံးဖို့ကြိုးစားလာတဲ့ ဂျာမန်မြို့ကလေး
ဥရောပနိုင်ငံတွေဟာ open-source နဲ့ပတ်သတ်လာရင် ပိုပြီးတော့ တစိုက်မတ်မတ် စိတ်ဝင်စားစား ပါဝင်ကြတယ်၊ contribute လုပ်ကြတယ်လို့မြင်မိပါတယ်။ OpenSUSE လိုမျိုး distro တစ်ခုကို မွေးဖွားပေးခဲ့တဲ့ ဂျာမနီနိုင်ငံဟာ ကျောင်းတွေ နဲ့ အစိုးရရုံးတွေမှာ open-source software တွေကိုပဲ အသုံးပြုဖို့လုပ်လာတာ တော်တော်ကြာပါပြီ။ အကြောင်းအမျိုးမျိုးကြောင့် ချက်ချင်းဆိုသလိုမျိုး user experience ကိုပြောင်းပစ်ဆိုတာ လွယ်တဲ့ကိစ္စတော့မဟုတ်ပါဘူး။ ဥပမာ Microsoft Windows ကိုကျွမ်းကျင်စွာသုံးနိုင်တဲ့ ရုံးဝင်ထမ်းတွေဟာ Linux distro တစ်ခုဖြစ်တဲ့ Ubuntu ကိုလုံးဝပြောင်းပစ်ဖို့ဆိုတာမျိုးက လက်တွေ့မှာ လုံးဝမလွယ်ပါဘူး။ ရုံးဝင်ထမ်းများအပြင် IT Support team အနေနဲ့လည်း Linux ကိုချက်ချင်း support လုပ်ဖို့က မဖြစ်နိုင်ပါ။ ဒီအတွက် လက်တွေ့မကျဘူး အချို့ကဆိုလာကြပါတယ်။ ဒီနှစ်ထဲမှာတော့ ဂျာမနီနိုင်ငံရဲ့ မြို့လေး တစ်မြို့မှာတော့ ချဉ်းကပ်ပုံက ကွာခြားပါတယ်။ အဲ့ဒီမြို့မှာ တမြို့လုံးက ရုံးမှာအသုံးပြုနေတဲ့ Microsoft Office Suite တစ်ခုလုံးကို LibreOffice နဲ့ စပြီးတော့ အစားထိုးပါတယ်။ User တွေအနေနဲ့ Windows ပေါ်မှာပဲ Microsoft Office ကနေ LibreOffice ပြောင်းသွားတာပဲရှိပါတယ်။ အဲ့ဒီနှစ်ခုဟာလည်း UI နဲ့ အသုံးပြုလို့ရတဲ့ function အပိုင်းမှာတော့ တော်တော်များများတူပါတယ်။ ဒါကို stage 1 အနေနဲ့ သူတို့ roll-out လုပ်ပြီးတော့ ဖြေးဖြေးချင်းစီမှာ open-source software တွေကိုပဲ အသုံးပြုနိုင်အောင် ကြိုးစားသွားမယ်လို့ ဆိုလာပါတယ်။ စိတ်ဝင်စားဖို့ ကောင်းတာတစ်ခုက OpenOffice ဟာတချိန်က Microsoft Office Suite ကိုဝယ်ပြီးတော့ မသုံးနိုင်တဲ့ University ကျောင်းသားတွေအတွက်တော့ open-source ဘက်ကိုရောက်လာအောင် စွဲဆောင်နိုင်စွမ်းရှိတဲ့ gateway drug တစ်ခုဖြစ်ခဲ့ရပါတယ်။ ဒီလိုပဲ အခုတခါလည်း LibreOffice ကိုရုံးမှာသုံးရင်း ရင်းနှီးကျွမ်းကျင်မှုရှိလာတဲ့အခါကြရင် အဲ့ဒီ ရုံးဝင်ထမ်းတွေ၊ အဲ့ဒီကျောင်းသား ကျောင်းသူတွေ အိမ်ကိုပြန်ရောက်တဲ့အခါ ဘာမှအကုန်အကျမရှိပဲနဲ့ LibreOffice ကို download ဆွဲပြီးတော့ အသုံးမယ်ဆိုရင်၊ စာရေးသူအမြင်မှာတော့ open-source အတွက် မျက်နှာပန်းပိုလို့ လှနိုင်စရာရှိပါတယ်။ Open-source မှာက marketing အတွက်အထူးတလည် ကြိုးစားတာမျိုး မရှိတဲ့အတွက်၊ လူတွေမသိပါဘူး။ သိတောင်မှ ကိုယ်နဲ့တိုက်ရိုက်ပတ်သတ်မှုမျိုး မရှိတဲ့အတွက် အထူးတလည် စိတ်ဝင်စားမှုလည်း မရှိနိုင်ပါ။ ဒီတော့... အခုလိုမျိုး ချဉ်းကပ်တာ လက်တွေ့ပိုဆန်တယ်လို့တော့ မြင်ပါတယ်။
(9) တိုင်ပတ်နေဆဲဖြစ်တဲ့ Microsoft နဲ့ Windows 11
ဒီနှစ်ထဲမှာ မပြောမဖြစ်ပြောရမယ့် နည်းပညာလောကထဲက အမှတ်တရတခုဟာ Windows 11 ပါ။ Microsoft က Windows 10 ကိုထုတ်တုန်းကတော့ ဒီ Windows ဟာနောက်ဆုံးနဲ့ အကောင်းဆုံး Windows ဖြစ်ပြီး point release သို့မဟုတ် point update ပုံစံမျိုးပဲ အသစ်ထွက်မယ်လို့ ဆိုပါတယ်။ အခု ၂၀၂၁ ခုနှစ်မှာတော့ အဲ့ဒီစကားဟာ အကြုံမဝင်တော့ပါဘူး။ Windows 11 ကိုထုတ်ပြီးသကာလ Linus Tech Tips လိုမျိုး YouTube နဲ့ Social Media ပေါ်က tech channel influencer တွေခြေချင်းလိမ်ပြီးတော့ ဘယ်လောက်တောင် စိတ်လှုပ်ရှားဖို့ကောင်းတဲ့ ဆိုတဲ့အကြောင်းကို ဖွဲ့နွဲ့ပြီးတော့ Windows 11 အတွက် promotion ပုံစံ video တွေအများကြီးအစောပိုင်းမှာ ထွက်လို့လာပါတော့တယ်။ ဒါဟာ sponsorship ကိုသုံးပြီးတော့လုပ်တဲ့ media campaign လို့ပဲထင်ပါတယ်။ Microsoft ရဲ့ Windows ထုတ်တဲ့ အစဉ်အလာအရတော့ ကောင်းတယ်လို့ထင်ရတဲ့ Windows version တစ်ခုထွက်လာပြီးရင်၊ နောက်ထွက်လာမယ့် Windows ဟာမကောင်းဖို့ သေချာသလောက်ရှိပါတယ်။ ဥပမာ - Windows XP အဆင်ပြေသလောက်၊ Windows Vista ကတိုင်ပတ်တယ်။ အဲ့ဒီနောက် Windows 7 ထွက်လာတော့ အားလုံးပြန်ကောင်းလာတယ်ဆိုနေတုန်းမှာ၊ Windows 8 ကို UI ကစလို့ အကုန်လုံး ပြောင်းပစ်ပြန်တယ်။ Windows 10 ထွက်လာတော့ Windows 8 မှာအဆင်မပြေတာတွေကို အဆင်ပြေအောင်လုပ်ပေးလို့ လူတွေကြိုက်နှစ်သက်တဲ့ UI နဲ့ user experience ကောင်းကောင်းရပြန်တယ်။ ကဲ... ကောင်းလို့မှမပြီးသေးဘူး အခုလည်း Windows 11 ဆိုပြီး experimental ဆန်ဆန် OS တစ်ခုကို ထုတ်ပြန်တယ်လေ။ စာရေးသူ စမ်းကြည့်သလောက်တော့ အခြေအနေမဟန်ပါဘူး။ Upgrade လုပ်ပြီးတာနဲ့ စပြီးတော့ အလုပ်မလုပ်တော့တဲ့ software တွေ၊ application တွေများတယ်။ ကိုယ့်စက်က Windows 11 ကို support လုပ်စေအုံးတော့ ချက်ချင်းတော့ upgrade မလုပ်သင့်သေးတဲ့ Windows version တစ်ခုပါ။
(10) AWS မှာလည်း outage တွေနဲ့
စာရေးသူတို့ နည်းပညာပိုင်းကလူတွေတိုင်းသိတဲ့ system outage / network outage ဆိုတာမျိုးဟာ ရှောင်လွှဲလို့ရနိုင်တဲ့အရာမဟုတ်ပါဘူး။ High Availability (HA) / Distributed Computing / Load Balancer / Replication နဲ့ အခြားသော magic words တွေနည်းပညာမှာ ကျွမ်းကျင်သူတိုင်းမှာရှိပါတယ်။ System တစ်ခုကို design လုပ်ကတည်းက ဘယ်လိုမျိုး ကောင်းသတဲ့ကောင်းအောင် တီထွင်ကြံဆပြီးမှ deploy လုပ်ကြပါတယ်။ သို့သော်... လက်ရှိအခုချိန်ထိ 100% uptime ကို မရနိုင်သေးပါဘူး။ ပြီးခဲ့တဲ့နှစ်က Google outage အကြောင်းကို ပြောတော့ Google ဖြစ်ပြီး outage တဲ့လာဆိုတာမျိုး ပြောစရာရှိပါတယ်။ Google ရဲ့ Site Reliability Engineer (SRE) တွေဆိုတာ DevOps Culture ကိုစတင်ခဲ့တဲ့ special role အနေနဲ့တောင်အတင်စားခံရတဲ့ဟာ လက်တွေ့မှာတော့ အခုလိုမျိုး outage တွေရှိနေပါသေးတယ်။ ဒီနှစ်မှာလည်း ပြီးခဲ့တဲ့ တပတ်မှာ Amazon Web Service (AWS) ရဲ့ outage ကြောင့် ထိခိုက်ဆုံးရှုံးရတဲ့ company တွေအများကြီးရှိပါတယ်။ သို့သော် AWS ရဲ့ availability zones တွေအကုန်လုံးမှာ outage ဖြစ်တာမျိုး မဟုတ်ပါဘူး။ အဲ့ဒီအတွက် ကိုယ့် infrastructure ဟာမတူတဲ့ zones မှာ HA သို့မဟုတ် DR ရှိရင်နေရင်တော့ mean time to recovery (MTTR) / mean time to restore (MTTR) ကပိုပြီးတော့ တိုပါလိမ့်မယ်။ Impact ကတော့ အနည်းနဲ့ အများရှိကြတဲ့အတွက် Cloud မှာ outage မရှိဘူးဆိုတာ လက်တွေ့သိပ်မကျတော့ပါ။ နှောင်နှစ်တွေမှာလည်း ဘယ်လိုမျိုး company ကြီးတွေ outage ဖြစ်မလဲဆိုတာလည်း စောင့်ကြည့်ရအုံးမယ့်တော့ ထင်ပါတယ်။
