သက္ကရာဇ်၂၀၂၀ ခုနှစ်တွင်း နည်းပညာဆိုင်ရာ အမှတ်တရလေးများ
ကမ္ဘာနဲ့ချီပြီးတော့ ဒုက္ခရောက်ကြတဲ့ သက္ကရာဇ် ၂၀၂၀ တွင်းမှာ ဘာကြောင့်လည်းလို့ မေးဖို့အားမရှိတော့ပါဘူး။ သိလည်း သိချင်စိတ်မရှိတော့လို့ ကျော်ကျော်သွားရတဲ့ နေ့စဉ်သတင်းများနဲ့ အတွေ့အကြုံဆိုးတွေဟာဖြင့် ယခုနှစ် ၂၀၂၀မှာဆို ဆိုးရွားလွန်းတဲ့ နက္ခတ်တွေ စုပြီးတော့ဝင်သလို တစ်ခုပြီးတစ်ခု အဆက်မပြတ် ဝင်လာတယ်။ ကိုယ်တိုင်က နည်းပညာနဲ့ လုပ်ကိုင်စားသောက်ရတာဖြစ်တဲ့အတွက် COVID-19 ကြောင့် lockdown ဖြစ်လိုက်ပြန်ဖွင့်လိုက် ပုံမှန်ဖြစ်မှာလိုနဲ့ ပြန်ဆိုးရွားလာလိုက်ဆိုပေမယ့်လည်း လေ့လာနိုင်စရာတွေအပြင် သက်ဆိုင်ရာ နည်းပညာသတင်းတွေကိုလည်း ဆက်တိုက်လိုက်ဖတ်ဖြစ်နေခဲ့ပါတယ်။ တနှစ်လုံးမှာလည်း မှတ်ကျောက်တင်နိုင်မယ့် Apple M1 chip ရဲ့ နည်းပညာဆိုင်ရာ တိုးတက်မှုတွေရှိသလိုပဲ၊ GitHub ပေါ်မှာ youtube-dl repo ကို DMCA takedown လုပ်ခိုင်းလို့ချက်ချင်း လုပ်လိုက်ပြီးကာမှ ရှက်ကိုးရှက်ကန်း funding တွေကို ပြန်ပြီးတော့လုပ်ပေးပါ့မယ်ဆိုတာလည်း ခပ်ကြောင်ကြောင်ရယ်ပါ။ ဘာကိုယုံလို့ယုံလိုက်ရမှန်း မသိတော့ပါ။ နှစ်ကုန်ပိုင်းရောက်လာလို့ နည်းနည်းလေး အေးချမ်းလာ မလာလို့တွေးလို့မှမပြီးသေးဘူး အခုလည်းကြည့်အုံးတော့ Solorigate တဲ့ဗျာ။ စာရေးသူဟို တလောကမှ CentOS 8 ကို Red Hat ကရပ်လိုက်တာနဲ့ ပတ်သတ်ပြီးတော့ အခဲမကြေတာ၊ အခုတော့ဖြင့် ရေရေလည်လည် ပြန်ပြီးစဉ်စားကြည့်ပြန်တော့ စိတ်ထဲမှာ လက်ဘက်ရည် ကျဆိမ့် တခွက်ကိုသောက်လိုက်ရသလို အိအိကလေး ဖြစ်နေပြန်ရော။ လူဆိုတာလည်း အာရုံ ၆ပါး အကုန်လုံး ဝါးမျိုလိုတဲ့ သတ္တဝါမျိုးမို့ စာရေးသူလည်း အကုန်လိုက်ပြီးတော့ ခံစားပေးနေပါတယ်။ ကိုယ်နဲ့ တိုက်ရိုက် ဆက်နွယ်မှု မရှိသော်လည်း မိမိကြိုက်နှစ်သက်တဲ့ opensource project / Linux distro တစ်ခုကို Red Hat လုပ်လိုက်ပုံကို သိပ်ပြီးတော့ ဘဝင်မကျလှပါဘူး။ Opensource နဲ့ဆိုပြီးတော့ လူကြားထဲမှာ ပျိုတိုင်းကြိုက်တဲ့ နှင်းဆီခိုင်က အခုကြမှ IBM big blue ကြီးရဲ့ လမ်းညွှန်ရာ စေခိုင်းအတိုင်းသွားလေသလား။ အခုလိုမျိုး COVID-19 တဖက်၊ သူ့ကြောင့် နေ့စဉ်တိုက်ပွဲဝင်ရတဲ့ စိတ်ပိုင်းဆိုင်ရာ အားပြိုင်မှုက တဖုံ၊ ဒီကြားထဲမှာ ကိုယ်နေ့စဉ် လှုပ်ရှား ရုန်းကန်ရတဲ့ နည်းပညာဆိုင်ရာ အလုပ်ထဲက မကောင်းတဲ့ သတင်းတွေကို လိုက်ပြီးခံစားပေးတာ တမျိုးမို့ စိတ်အနားမရတာ အမှန်ပါ။ ဘဝမှာတော့ ဘယ်လို ပြဿနာမျိုးမဆို ကိုယ်တိုင်ယူတတ်က သင်ယူနိုင်စရာ အခွင့်အရေးတစ်ခုပဲလို့ နောက်ပိုင်းမြင်လာနိုင်စွမ်း ရှိလာတယ်။ အခုလည်း ၂၀၂၀ နှစ်ကုန်ခါနီးမှ နည်းပညာဘက်မှာ ထပ်ပြီးတော့ opensource ဆိုင်ရာ သင်ယူစရာ နှစ်ခုကို အသုံးချပြီးတော့ တချိန်တုန်းက စာရေးသူ သေချာရှင်းလင်းအောင် မဖြေနိုင်မေးခွန်း တစ်ခုကို ကိုယ့်အတွက်ကော၊ ကိုယ့်ကို မေးခဲ့တဲ့သူတွေအတွက်ပါ ဖြေဖို့အတွက် အချက်ကျကျ စဉ်းစားသုံးသပ်ကြည့်ရအောင်။
Apple M1 Chip နဲ့ ARM သတင်း
ဒီလို ARM နဲ့ implementation လုပ်တာမျိုးတွေဟာ opensource ကမ္ဘာမှာတော့ သိပ်ပြီးတော့ ထူးဆန်းတဲ့ ကိစ္စတစ်ခုမဟုတ်တာတော့ အမှန်ပါ။ ARM platform တွေကို Android နဲ့ Raspberry Pi တို့လို platform တွေမှာ နှစ်အနည်းငယ်ကြာကြာ စမ်းသပ်အသုံးပြုလာကြတာ အခုဆိုရင် တော်တော်လေးကို စုံစုံလင်လင် နေရာတိုင်းမှာ အသုံးပြုနိုင်တဲ့ အနေအထားမျိုးရောက်လို့ နေပါပြီ။ ဆိုပါတော့ Android လိုမျိုး mobile platform တွေကစလို Raspberry Pi နဲ့ သူနဲ့ဆိုင်တဲ့ IoT device တွေအပြင် ARM နဲ့ processing လုပ်တဲ့ performance မြင့် server တွေဟာလည်း လက်တွေ့ အသုံးဝင်တဲ့ အသုံးပြုပုံတွေပဲလိုဆိုရမှာပါ။ သို့သော်လည်း Apple ရဲ့ အစဉ်အလာအရ product တစ်ခု နည်းပညာအသစ် တစ်ခုကို စတင်မိတ်ဆက်ပုံနဲ့ hardware/software platform တွေကို စနစ်တကျကြိုတင်ပြင်ဆင်တတ်တဲ့သဘောရှိတာကြောင့် Apple M1 ARM Chip ဟာ ၂၀၂၀ခုနှစ်ကုန်ခါနီးကြမှ လူတွေ ပါးစပ်ဖျားမှာ ရေပန်းစားလို့ နေပြန်တယ်။ product တွေကို launch လုပ်တဲ့နေရာမှာ လူအများ စိတ်ဝင်စားအောင် တင်ပြပုံ တင်ပြနည်း ကောင်းကောင်းတွေကို အသုံးပြုတဲ့အပြင်၊ လူပိန်းတွေပါ နားလည်ရလွယ်အောင်လို့ ဘယ် generation မှာထုတ်တဲ့ ဘယ် Macbook ထက်ဘယ်လောက်မြန်သလဲဆိုတဲ့ ရှင်းပြချက်တွေကိုလည်း တွင်တွင်ကျယ်ကျယ် ထည့်သုံးသွားတယ်။ စာရေးသူ အတွက်တော့ ကိုယ်တိုင်က ၂၀၁၅ လောက်ကထွက်တဲ့ Macbook တစ်လုံးကို Apple ရဲ့ Ecosystem အကြောင်းကို ရိပ်ဖမ်းသံဖမ်း ရှိအောင်သာ ဝယ်ယူထားပြီးတော့ အသုံးပြုဖြစ်ခဲ့ပါတယ်။ သို့သော် သူ့ရဲ့ MacOS ကို end user တစ်ယောက်အနေနဲ့ တော့ စာရေးသူ ကြိုက်နှစ်သက်တာမျိုးတော့ မရှိပါဘူး။ Apple က developer တွေအဆင်ပြေအောင် သူ့ OS မှာ bash လိုမျိုး terminal emulator ကောင်းကောင်း တစ်ခုထည့်ထားပေးသည့်တိုင်အောင် Linux မှာရနိုင်တဲ့ package manager ပုံစံမျိုးကို native အနေနဲ့ အသုံးပြုလို့ မရနိုင်ပါဘူး။ Homebrew လိုမျိုး third-party package manager software ကို install လုပ်ပြီးတော့မှပဲ developer တွေနဲ့ Linux system admin တွေ ရင်းနှီးတဲ့ platform ပုံစံမျိုး ထွက်လာပါတော့တယ်။ Performance အနေနဲ့တော့ native မဟုတ်တဲ့ အတွက်အတော်လေးကို နှေးတယ်လို့တော့ ထင်မြင်မိပါတယ်။ ဒီတော့... စာရေးသူဟာ Apple ကိုကြိုက်တဲ့ Apple fan တစ်ယောက် မဟုတ်တဲ့ အတွက် Apple M1 Chip အတွက် ဒီလောက်ကြီး ရင်ခုန်ဖွယ်ရာ ဖြစ်မနေပါဘူး။ သို့သော်... Apple ဘယ်လိုမျိုး ပုံစံနဲ့ approach လုပ်သလဲ၊ product launch ပိုင်းမှာ strategy ကောင်းတွေဘယ်သုံးမှာလဲ၊ ဘယ်လိုမျိုး ARM chip ရဲ့ consumer market တစ်ခုတည်ဆောက်မှာလဲဆိုတာတော့ သိချင်စိတ်ဖြစ်မိတာတော့ အမှန်ပါ။
အခုဆိုရင် Apple M1 ထွက်တာ လအနည်းငယ်ကြာပြီးတဲ့ နောက်လူတွေ ပြောလာတဲ့ Apple M1 အကြောင်းဟာ နည်းပညာလောကအတွက်တော့ သတင်းကောင်းတွေပါပဲ။ ARM လိုမျိုး processing algorithm ကိုအသုံးပြုထားသည့်တိုင်အောင် Intel ရဲ့ x86 platform မှာလိုမျိုး performance ရတယ်ဆိုတဲ့ အသံတွေကြားရတယ်။ နောက်တခါ... battery consumption မှာ ARM ကိုသုံးတဲ့အတွက် x86 မှာထက် အများကြီး သိသိသာသာကောင်းလာတာလည်း တွေ့ရတယ်လို့ ဆိုပြန်တယ်။ Cooling မှာလည်း Fan တစ်ခုမှ မထည့်ထားပဲနဲ့ passive cooling ကိုအသုံးပြုထားတဲ့အတွက် Youtuber တွေနဲ့ Podcaster တွေလည်း အကြိုက်တွေ့့နေကြတယ်။ ထူးခြားတာတစ်ခုကတော့ Apple M1 Chip ဟာ ARM CPU တစ်ခုတည်းပါဝင်တာမဟုတ်ပဲနဲ့ အခြားသော GPU နဲ့ RAM လိုမျိုးဟာတွေကို တစ်ခုတည်းမှာ ပေါင်းပြီးတော့ ထည့်ထားတာပါ။ ဒီတော့... storage တစ်ခုတည်း ဖြုတ်လဲလို့ ရမယ့် အနေအထားမျိုးပါ။ အခြားသော RAM တို့ GPU တို့ ကို upgrade လုပ်ချင်ရင်တော့ နောက်ထွက်တဲ့ new generation ကိုလိုက်ဝယ်ရမှာ ဖြစ်လို့ Apple ရဲ့ product တစ်ခုကို profitable ဖြစ်အောင် ဘယ်လိုမျိုး ထုပ်ပိုးသလဲဆိုတာ Apple M1 မှာ ရှင်းရှင်းလင်းလင်းကြီး ဖော်ပြနေတဲ့ သဘောပါ။ Apple က hardware နဲ့ software နှစ်ခုလုံးရဲ့ end-to-end stacks အားလုံးကို leverage ကောင်းကောင်းနဲ့ အသုံးပြုပြီးတော့ အခြားသောပြိုင်ဘက်တွေ market ထဲကို ဝင်ရခက်အောင်လို့ လုပ်နိုင်စွမ်းရှိတာတော့ အမှန်ပါ။ သို့သော် နည်းပညာ market မှာတော့ Apple က ခင်းသွားလို့ နောက်ကလိုက်လုပ်ကြတဲ့ စံနမူနာလေးတွေ ရှိတာကြောင့် ARM အတွက်လည်း ရှေ့ရေးအတွက် အလားအလာအများကြီးရှိတဲ့ ပုံစံပါ။ CPU မှာ Intel ဟာ market leader အနေနဲ့ နေရာယူထားတာကြာပါပြီ။ AMD ကလည်း အခုနောက်ပိုင်း Intel ထက်ကောင်းတဲ့ x86 တွေကိုထုတ်လုပ်နေနိုင်ပြီဖြစ်လို့ ARM ဟာ အားလုံးအတွက် စိတ်ဝင်စားစရာကောင်းတဲ့ ပြိုင်ဘက်ကောင်း တစ်ယောက်ဖြစ်လာမှာတော့ မလွှဲမသွေပါပဲ။ Apple M1 ဟာ စာရေးသူအမြင်တော့ နည်းပညာလောကကြီး တစ်ခုလုံးအတွက် သတင်းကောင်းပါ။
GitHub ပေါ်က youtube-dl ကို DMCA takedown
youtube-dl ကို စာရေးသူ အချို့သော youtube tutorial ကောင်းကောင်းတွေကို download လုပ်ပြီးတော့ ကိုယ့်အိမ်က media server ပေါ်မှာ နောက်ပြန်ကြည့် ရအောင်လို့ archive လုပ်ဖို့အတွက် သုံးလာတာ နည်းနည်းတောင်ကြာပါပြီ။ တော်တော်လေးကို အသုံးဝင်တဲ့ CLI tool လေးတစ်ခုပါ။ Youtube အပြင်အခြားသော media streaming platform တွေမှာလည်း video တွေ၊ အသံဖိုင်တွေကို download လုပ်လို့လည်း ရပါတယ်။ Back-end မှာတော့ Python ကို core language အသုံးပြုထားတာဖြစ်ပြီးတော့ GitHub မှာသူ့ Repo ကို opensource လုပ်ထားပါတယ်။ လက်ရှိမှာတော့ contributor ပေါင်း ၇၀၀ ကျော် ၈၀၀ လောက်ရှိပါတယ်။ GitHub မှာ DMCA takedown မတိုင်ခင်က အသုံးပြုတဲ့ ရှိသော်လည်း ထင်သလောက်တော့ များမယ်မထင်ပါ။ စေ့စေ့ပေါက်ပေါက် လိုက်ရှာမှာပဲ youtube-dl cli ကို Linux မှာအလွယ်တကူ အသုံးပြုနိုင်ကြောင်း သိမှာဖြစ်လို့ စာရေးသူလိုမျိုး use case မျိုးရှိမှာပဲ ရှာတွေ့နိုင်မှာပါ။ ဒါမှမဟုတ်ရင်တော့ မျက်စိကျော်သွားကြမယ်လို့ထင်ပါတယ်။ သို့သော်လည်း DMCA takedown ကိစ္စနဲ့ ပတ်သတ်ပြီးတော့ လူအတော်များများဟာ youtube-dl အကြောင်းကို တော်တော်များများ သိလာကြပြီးတော့ သုံးတဲ့သူပို့လိုတောင်များလာပါသေးတယ်။
GitHub မှာ takedown request လုပ်ပြီး ၂၄နာရီအတွင်းမှာပဲ သူ့ရဲ့ repo ဟာလူမသိသူမသိ ချက်ချင်းဆိုသလိုပျောက်ချင်းမလှပျောက်သွားတာဖြင့် repo owner ဖြစ်တဲ့သူတောင် notification မရလို့ သူ့ repo မှာတစ်ခုခုများ ဖြစ်သလားလို့တောင်တွေးမိပါသတဲ့။ နောက်တော့မှ GitHub က takedown လုပ်သွားတာကိုသိရတယ်လို့ ဆိုပါတယ်။ ဒါကိုကြည့်ခြင်းအားဖြင့် GitHub ဘက်မှာဒီလို takedown request လာရင်ဘယ်လို ကိုင်တွယ်ရမယ်ဆိုတဲ့ လုပ်ငန်းစဉ်သတ်မှတ်ချက် ရှင်းရှင်းလင်းလင်းရှိထားပုံမရပါ။ Youtube-dl နဲ့မှ ပထမဆုံး လုပ်ဆောင်ရတဲ့ repo takedown ပုံစံမျိုးဖြစ်နေပါတယ်။ အခုလိုမျိုးဖြစ်ရပ် youtube-dl ကိစ္စလူတွေကြားမှာ အပြောများလာသည့်အလောက် youtube-dl ကို လူသိပိုများလာပြီးနောက် လူတွေကလည်း ပိုလို့ပင်အသုံးများလာပါတော့တယ်။ Takedown ကြောင့် original repo ဟာ GitHub မှာပျောက်သွားပြီးနဲ့နောက်မှာတော့ youtube-dl repo ကို fork လုပ်ထားတဲ့ repo တွေကိုလည်း ဘယ်လိုမျိုးကိုင်တွယ်မလဲဆိုတာကိုလည်း အားလုံးကစိတ်ဝင်စားလာကြပါတော့တယ်။ Source code ရှိတဲ့သူတွေကလည်း အခြားသော GitLab လိုမျိုး platform တွေမှာ ပြောင်းပြီးတော့ တင်လာကြပါတယ်။ နောက်ဆုံး တစ်လကျော်ကျော်လောက် အကြာမှာတော့ takedown ကို ပြန်လည် ရုတ်သိမ်းပေးလိုက်ပြီးတော့ ဒီလိုမျိုးကိစ္စနှောင်များမှာ ဖြစ်လာခဲ့လို့ရှိရင်ဖြင့် ဥပဒေအရ လုပ်ဆောင်စရာရှိတာကို လုပ်လို့ရအောင်လို့ ငွေအများကြီးပြန်လည်မတည်ခဲ့ပေးခြင်းဖြင့် အဖက်ဆည်ရပါတယ်။ စာရေးသူရဲ့ အတွေ့အကြုံအရ အဲ့ဒီနောက်ပိုင်းမှာလည်း youtube-dl ကို maintain လုပ်တဲ့သူ မရှိတော့တာလား မလုပ်တော့တာလာတော့ မသိဘူး ဆက်ပြီးတော့အသုံးပြုလို့ မရတဲ့အထိဖြစ်လာတော့မှ ဟိုရှာကြည့်ဒီရှာကြည့်နဲ့နောက်ဆုံးမှာတော့ သူ့ကို fork လုပ်ထားတဲ့ repo နောက်တစ်ခုကို ထပ်မံတွေ့ရှိခဲ့ပြန်ပါတယ်။ GitHub repo ကိုတော့အောက်ကအတိုင်းသွားပြီးတော့ ကြည့်လို့ရပါတယ်။ အသုံးပြုကြည့်သလောက်တော့ အကုန်လုံးနီးပါးအဆင်ပြေနေပါသေးတယ်။
Google outage ဖြစ်ရပ်မှ မေးစရာမေးခွန်းများ
၂၀၂၀ခုနှစ် ဒီဇင်ဘာလထဲမှာ ဘယ်သူမှမထင်ထားတဲ့ Google outage တစ်ခုဖြစ်ခဲ့ပါတယ်။ နေ့အားဖြင့် ဒီဇင်ဘာ ၁၅ရက်နေ့ အင်္ဂါနေ့ဖြစ်ပြီးတော့ outage ဖြစ်နေတဲ့အချိန်အတွင်းမှာ Google ရဲ့ services တွေအကုန်လုံးနီးပါး အသုံးပြုလို့မရတဲ့အထိဖြစ်ခဲ့ပါတော့တယ်။ ဖြစ်တဲ့အချိန်ဟာ အမေရိကနိုင်ငံ အရှေ့ပိုင်းမှာ မနက်စောစော ၈နာရီထိုးခါနီးလောက်က စပြီးတော့အသုံးပြုလို့ မရတာကိုကြုံတွေ့ခဲ့သည့်တိုင်အောင်မှ Google ရဲ့ automated reporting system နဲ့ monitoring system တွေဟာအဲ့ဒီ outage ကိုလုံးလုံး အသိမပေးခဲ့တဲ့အတွက် Google က ပထမ မိနစ် ၃၀အတွင်းမှာဘာမှ မလုပ်ခဲ့ဘူးလို့လည်းသိရပါတယ်။ ထို မိနစ်၃၀ ပြီးမှနောက်ပိုင်းမှာ Google ကသူတို့ တရားဝင်ဆိုဒ်မှာ အဲ့ဒီ outage ကိုအသိပေးကြေငြာပါတော့တယ်။ အဲ့ဒီနောက် ဆက်လက်စုံစမ်းစစ်ဆေးပြီးတဲ့နောက်မှာတော့ authentication system တစ်ခုက ထဖေါက်လို့ ရှိသမျှ Google services တွေရပ်သွားပါကြောင်း သိရှိရပါတော့တယ်။ ဟုတ်ပြီ... Google လိုမျိူး company မျိုးမှာ authentication system တစ်ခုက အလိုလိုနေရင်းထဖေါက်ရတဲ့ အကြောင်းအရင်းကို ရှာလိုက်တော့ storage မှာ full ဖြစ်ပြီးတော့ system crash ဖြစ်တာပါတဲ့ဗျာ။ Google မှာအခုလိုမျိုး storage ကိုတောင် monitor သေချာမလုပ်နိုင်ဘူးလားဆိုတော့ လုပ်နိုင်ပါတယ်။ သူတို့ရဲ့ အသုံးပြုတဲ့ automated workflow ကကြောင်ပြီးတော့ reporting လည်းမလုပ်တော့သလို၊ auto-scaling လည်းမလုပ်တော့တဲ့ အထိအကုန်မှားခဲ့ပါတယ်။ ဒီတော့... ဒီနေရာမှာ မှတ်သားရမှာက system တစ်ခုရှိတာတဲ့ outage ဆိုတာ downtime ဆိုတာ ရှိနေအုံးမှာပဲဆိုတာကိုပါ။ ကောင်းပြီ စာရေးသူတို့ Google လည်း outage ရှိနိုင်တယ်ဆိုတာကို လက်ခံကြပြီဆိုအုံးတော့... နောက်မှာဆက်ပြီးတော့ စဉ်းစားရမှာက အဲ့ဒီ outage ကနေဘာတွေဆက်ဖြစ်ခဲ့လဲ၊ outage အချိန်အတွင်းမှာကော ဘာတွေဖြစ်နေသလဲဆိုတာကို တချက်ကြည့်လိုက်ရအောင်။
Google outage ကြောင့် သုံးလို့မရတဲ့ Gmail and Google Calendar လိုမျိုး free အသုံးပြုနိုင်တဲ့ service တွေအပြင်၊ G suite လိုမျိုး enterprise customer တွေမှာလည်း subscribe လုပ်ထားတဲ့ service တွေလည်းတစ်ခုမှ အသုံးပြုလို့ မရပါ။ YouTube ရဲ့ streaming ကလည်း အဲ့ဒီအချိန်မှာ လုံးဝအလုပ်မလုပ်တော့ပါ။ ပိုပြီးတော့ ဆိုးတာက G suite မှာ business အတွက်အသုံးပြုတဲ့ Google Docs၊ Sheets နဲ့ Slides လို service တွေလည်းဘာမှ ဆက်သုံးလို့မရတဲ့အတွက် presentation လုပ်စရာရှိတာတွေမလုပ်ရ၊ Google Drive မှာသိမ်းဆည်းထားတဲ့ files တွေကိုလည်း ဘာမှ access လုပ်လို့မရတဲ့အတွက် business အတွက် Google ကိုအားကိုးရတဲ့ companies တွေနားကားခဲ့ရပါတယ်။ ဒါပဲလားဆိုတော့... Google account ကိုအသုံးပြုပြီးတော့ sign in လုပ်ထားတဲ့ အခြားသော third-party service တွေမှာလည်း authentication failure ကြောင့် အသုံးပြုလို့မရခဲ့တာတွေလည်း ရှိခဲ့ပါတယ်။ နောက်ဆုံး ကုန်ကုန်ပြောရရင်... ကိုယ့်အိမ်မှာ Google Home တို့ Nest တို့ကို အသုံးပြုပြီးတော့ Smart Home ရဲ့ အခြားသော accessories တွေကိုအသုံးပြုတဲ့သူတွေအတွက်တော့ မီးသီးလေးတစ်လုံးကို voice command နဲ့ ဖွင့်ဖို့ရာ ဖွင့်မရလို့ အမှောင်ထဲမှာ ဒီအတိုင်း ထိုင်နေရတဲ့ အထိပါပဲ။ Nest ကိုအသုံးပြုပြီးတော့ thermostat နဲ့ air-conditioning system ထိန်းသိမ်းတဲ့ဟာတွေလည်း အလုပ်မဖြစ်တော့ပါ။ အခြားသော Google နဲ့ ချိတ်ထားတဲ့ security camera တွေနဲ့ alarm system တွေပါသုံးလို့မရခဲ့ပါဘူး။ စာရေးသူတို့ Google ကိုဘယ်လောက်တောင် မှီခိုလွန်းလိုက်နေပြီဆိုတာ အများကြီးတွေးစရာတစ်ခုဖြစ်လာပါတော့တယ်။ အဲ့ဒီ Google outage က ၄၅ မိနစ်လောက်သာကြာခဲ့ပေမယ့် မေးစရာ မေးခွန်တွေကတော့ စာရေးသူတို့အတွက် အများကြီးရှိခဲ့ပါတော့သည်။
Solorigate နဲ့ supply chain attack
COVID-19 နဲ့လုံးပန်းနေရတဲ့ သက္ကရာဇ် ၂၀၂၀ဟာ အားလုံးအတွက် စိတ်ရောလူပါ တော်တော်လေးကို ရုန်းကန်ခဲ့ရတာဟာ တကမ္ဘာလုံးအတွက် အခက်ခဲဆုံးအချိန်တွေကို ဖြတ်သန်းခဲ့ရတာတော့အမှန်ပါ။ နည်းပညာမှာလောကထဲမှာလည်း Solarwinds breach ဖြစ်လို့ သူ့ရဲ့ Network Performance Monitoring (NPM) ကိုအသုံးပြုတဲ့ company တော်တော်များများ လှန့်ဖြန့်ကုန်ပါတော့တယ်။ ပိုပြီးတော့ဆိုတာက supply chain attack လည်းဖြစ်၊ သူ့ရဲ့ သဘာဝအရ အတွင်းထဲမှာ malicious code တွေကိုနည်းနည်းချင်းစီ ထည့်သွင်းနေတာမို့ အချိန်အားဖြင့် ဘယ်လောက်ကြာကြာလောက်ကတည်း ရောက်နေသလဲဆိုတာ သေချာပြောလို့ မရနိုင်ပါဘူး။ ထွက်လာတဲ့ သတင်းတွေအရတော့ ၂၀၁၉ ခုနှစ် နှစ်အလယ်လောက်ကတည်းကနေပြီးတော့ code တွေကို merge လုပ်လို့ရနိုင်တဲ့ pipeline တစ်ခုလုံးကို access ရနေပြီးသားလို့ လည်းဆိုပါတယ်။ ၂၀၂၀ နှစ်ကုန်ပိုင်းမှာတော့ FireEye ဆိုတဲ့ security company တစ်ခုကနေပြီးတော့ စတင်သတိထားမိလာတာလည်း ဖြစ်ပါတယ်။ FireEye မှာအလုပ်လုပ်တဲ့ ဝန်ထမ်းတစ်ယောက်ကနေပြီးတော့ multi-factor authentication (MFA) request တစ်ခုရလာပြီတော့ ၄င်းက report လုပ်ရာကနေပြီးတော့ FireEye ကစတင် သတိထားပြီးတော့ အကုန်လုံးသိအောင် publish လုပ်ပါတယ်။ အဲ့ဒီအချိန်ကျမှ Solarwinds ကသိရပြီးတော့ အကုန်လုံးကို ပြန်လိုက် စစ်ရပါတော့တယ်။ ပြီးတော့မှ ဘယ် release မှာ malicious code ဘယ်လောက်ပါသွားတယ်၊ ဘာလိုပါသွားတာလည်း ဆိုတာတွေကို ရင်တမမနဲ့ Solarwinds NPM ကိုအသုံးပြုနေတဲ့ customer တွေကစောင့်မျှော်ရပါတယ်။ NPM ကိုသုံးတဲ့ အထဲမှာ US ရဲ့ အစိုးရရုံးများ နဲ့ ထောက်လှမ်းရေးဆိုင်ရာ အဖွဲ့အစည်းတွေပါလာတာမို့ ဒီကိစ္စက သေးမွှားတဲ့အရာမဟုတ်မှန်လည်း US အစိုးရအဖွဲ့ရိပ်စားမိလာပါတော့တယ်။ သူ့တို့ ထုတ်ပြန်တဲ့သတင်းထဲမှာတော့ ဒီ attack ရဲ့နောက်ကွယ်မှာ Russia ရဲ့ အစိုးရ ကျောထောက်နောက်ခံပေးထားတဲ့ hacker တွေကလုပ်တာဖြစ်တယ်လို့ သတင်းထက်ထွက်လာပြန်ပါတယ်။ ဒီလိုနဲ့ ၂၀၂၀ခုနှစ် နှစ်ကုန်ပိုင်းလောက်ကတည်း စလိုက်တဲ့ chain of events တွေဟာ အခုအချိန် ဒီစာကို ရေးနေတဲ့ မေလ ၂၀၂၁ခုနှစ်ပိုင်းထိကို မပြီးနိုင်တော့ပါဘူး။ ပိုပြီးတော့ စိတ်ဝင်စားဖို့ကောင်းတာက ပြီးတဲ့အပတ်ကထွက်တဲ့ သတင်းထဲမှာ Solarwinds ရဲ့ stock price က ၂၅ - ၃၀ ရာခိုင်နှုန်းကြား ထက်တက်သွားတယ်ဆိုတဲ့ သတင်းပါ။ ဒါ့အပြင် Solarwinds ရဲ့ support ဖြစ်တဲ့ maintenance price ကိုလည်း Solarwinds ကထပ်ပြီးတော့ စျေးကိုမြင့်တင်လိုက်ပြန်ပါတယ်။
ရေပူရအားဖြင့် platform တစ်ခုမှာ breach ဖြစ်တယ်၊ data leak ဖြစ်တယ်ဆိုရင် ရောင်းအားကျမယ်၊ company အနေနဲ့ အရှုံးပေါ်မယ်ဆိုတာမျိုး ဖြစ်မယ်ဆိုတာမျိုး ကြိုတင်တွက်ချက်လို့ ရနိုင်ပါတယ်။ အခုဟာက အရှုံးမပေါ်ပဲနဲ့ NPM platform ကိုပိုပြီးတော့ လုံခြုံအောင်သာလုပ်ထားပေး အသုံးပြုသူတွေအနေနဲ့ ပိုပေးမယ်ဆိုတာမျိုး တွေးပုံတွေးနည်းကို သွားပြီးတော့တွေ့ရပါတယ်။ ဖြစ်နိုင်ချေတစ်ခုက တကမ္ဘာလုံး COVID-19 ကြောင့် စိတ်ကောကိုယ်ပါ မောပန်းနေလို့ company ကြီးတွေနဲ့ အစိုးရအဖွဲ့ဝင်တွေ ဘက်က အလုပ်လုပ်နေသေးတဲ့ platform တစ်ခုလုံးကို ဖြုတ်ပြီးတော့ အစကနေပြန်ပြီးတော့ မစချင်တာလည်း ပါနိုင်သလို၊ Solarwinds ရဲ့ product တွေတော်တော်များများကို အခြားသော network အစိတ်အပိုင်းတွေနဲ့ integration လုပ်ထားတာ တော်တော်လေး ထဲထဲဝင်ဝင်ဖြစ်နေလို့ အစကနေပြီး ပြန်လုပ်ဖို့ရာအတွက် လက်ဝင်မယ့်သဘောရှိနေနိုင်ပါတယ်။ Solarwinds ရဲ့ NPM ဟာ အခြားအခြားသော product တွေနဲ့ပေါင်းပြီးတော့ syslog နဲ့ network automation အတွက် event trigger တွေကိုလည်း ဖန်တီး နိုင်စွမ်းရှိတာမို့ ကောင်းမွန်တဲ့ network montoring platform တစ်ခုပါ။ အခုလိုမျိုး ဖြစ်လာလိုက်တာဟာ အခြားသော proprietary software တွေမှာလည်း အတွင်းထဲမှာ ဘယ်လိုမျိုး workflow နဲ့ process တွေမှာ flaw တွေရှိနိုင်သလဲဆိုတာမသိနိုင်ပါဘူး။ ဒါဟာ opensource နဲ့ ကွာခြားချက်တစ်ခုပါ။ စာရေးသူပြောချင်တာက အခုလိုမျိုး supply chain attack မျိုးဟာ opensource မှာလည်းဖြစ်နိုင်သလို၊ proprietary မှာလည်း ဖြစ်နိုင်တာချင်းအတူတူ proprietary မှာ ငွေကြေးအများကြီးပေးပြီးတော့ software license အတွက်ပေးရတာဟာ သဘာဝမကျတဲ့ သဘောပါ။ ဒီ့အတွက် opensource မှာ အားသာချက်များစွာရှိနေပါတယ်။ ပြီးခဲ့တဲ့ လထဲ University of Minnesota က contribute လုပ်တဲ့ commits တွေထဲမှာ malicious code ကို ရည်ရွယ်ချက်ရှိရှိနဲ့ ထည့်ပေးလိုက်တာကို Linux kernel ရဲ့ gatekeeper ဖြစ်တဲ့ Greg Kroah-Hartman ကြီးဘယ်လိုမျိုး handle လုပ်သွားသလဲ၊ Linux Foundation ကဘယ်လိုမျိုး action လုပ်သွားသလဲဆိုတာကို ကြည့်လိုက်ရင် opensource model ဘယ်လောက်ထိ အလုပ်ဖြစ်သလဲဆိုတာကိုတွေ့နိုင်ပါတယ်။
RHEL ရဲ့ CentOS အတွက်နောက်ဆုံးနှုတ်ဆက်ခြင်း
စာရေးသူအတွက်တော့ CentOS ဟာ enterprise Linux server တစ်ခုအတွက်အကောင်းဆုံး distribution တစ်ခုပါ။ Ubuntu ရဲ့ LTS တွေကိုလည်း server အနေနဲ့ အသုံးဖြစ်သလို၊ CentOS ကိုတော့ ပိုပြီးတော့ ကြိုက်နှစ်သက်မိတာတော့ အမှန်ပါ။ CentOS ရဲ့ အားသာချက်ကတော့ RHEL ရဲ့ stable ဖြစ်တဲ့ အရာမှန်သမျှကို ယူပြီးတော့ အသုံးပြုထားလို့ တကယ့် production ထဲမှာ အသုံးပြုရာအတွက် အဆင့်သင့်ဖြစ်နေသလိုမျိုး ဖြစ်နေပါတယ်။ EPEL ရဲ့အစွမ်းကြောင့် ကိုယ်လိုတဲ့ package တွေကိုထပ်တိုးပြီးတော့ ပေါင်းထည့်လို့ရတာမို့ RHEL မှာရနိုင်တဲ့ဟာတွေ အကုန်လုံးကို CentOS မှာလည်း ရနိုင်နေတဲ့ သဘောမျိုးသွားဖြစ်နေပါတယ်။ ဒါကြောင့်လည်း web hosting တွေတော်တော်များများမှာ CentOS ကိုတွင်တွင်ကျယ်ကျယ် အသုံးပြုနေရတာလည်း ဖြစ်ပါတယ်။ ဒါကြောင့်လည်း IBM ကနေပြီးတော့ Red Hat ကိုဝယ်ပြီးနောက်ပိုင်းမှာ product ရောင်းအားတက်အောင်လို့ ကြိုးပမ်းတဲ့နေရာမှာ အခုလိုမျိုး ဆုံးဖြတ်ချက်ကို ရွေးလိုက်ခြင်းဖြစ်ပါတယ်။ Red Hat ဘက်ကအဲ့ဒါကြောင့် မဟုတ်ရပါဘူးလို့ ဆိုသော်လည်း အားလုံးကဘာကြောင့် ဘာအတွက်လုပ်သလဲဆိုတာကို သိနေကြပါတယ်။ ဒီကိစ္စက open secret ပါ။ IBM က Red Hat ကိုဝယ်ပြီးကတည်းက အခုလိုမျိုး ဖြစ်လာတော့ မယ်ဆိုတာမှန်းဆလို့ ရနိုင်ပါတယ်။
အခုလိုမျိုး Red Hat က CentOS 8 ရဲ့ support ကို ၂၀၂၁ ခုနှစ် ဒီဇင်ဘာလ ၃၁ရက်နေ့ ရပ်နားမယ်လို့ သတင်းထွက်လာတော့ CentOS 7 ကနေ 8 ကိုမကြာသေးခင်ကမှ upgrade လုပ်ထားတဲ့ company တွေအတွက်တော့ သောကများရပါတော့တယ်။ Red Hat က CentOS 8 ကို RHEL 8 အနေနဲ့ ဆက်လက်အသုံးပြုလိုက သုံးနိုင်အောင်လို့ script တွေကို ပေးထားသော်လည်း RHEL 8 အတွက်တော့ support license ရှိမှရပါတော့မယ်။ CentOS 7 ကိုအသုံးပြုနေသေးတဲ့ company တွေအတွက်တော့ ၂၀၂၄ ဇွန်လ ၃၀ရက်နေ့ အထိဆက်လက် အသုံးပြုနိုင်မှာဖြစ်ပါတယ်။ CentOS 8 ရဲ့ support ကိုရပ်မယ်လို့ သတင်းထွက်လာကတည်း Rocky Linux နဲ့ AlmaLinux OS project နှစ်ခုလုံး RHEL 8 ရဲ့ clone ကို ဆက်ပြီးတော့ maintain လုပ်ပြီးတော့ CentOS ရဲ့နေရာကို ဆက်လက် ထိန်းသိမ်းဖို့ ပြောလာကြပါတယ်။ အခုဆိုရင် AlmaLinux ကိုစတင်အသုံးပြုလို့ရတဲ့ အနေအထား တစ်ခုရောက်နေပြီဖြစ်သလို၊ Rocky Linux ဟာလည်း အခုပုံစံတိုင်းဆိုရင် နောက်လအနည်းငယ်အတွင်းမှာ စတင်အသုံးဖို့အတွက် အဆင်သင့်ဖြစ်လာတော့မှာပါ။
Last updated
Was this helpful?