การพัฒนาแอปสำหรับ Linux

 (makealinux.app)
1 คะแนน โดย GN⁺ 2023-12-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บน Linux ทั้งเดสก์ท็อปและมือถือยังมีความต้องการซอฟต์แวร์ใหม่ แต่ใน app store และคลังซอฟต์แวร์ยังมีจำนวนแอปพลิเคชันไม่เพียงพอ จึงเป็นการส่งสารให้หันมาโฟกัสการพัฒนาแอปมากกว่าการสร้างดิสทริบิวชันใหม่
  • แม้แอปจะเริ่มจากความต้องการส่วนตัว แต่หากพัฒนาแบบเปิดเผยต่อสาธารณะ ก็อาจกลายเป็นทั้งแหล่งเรียนรู้และชุมชนที่ช่วยขยายระบบนิเวศ Linuxได้
  • ความหลากหลายที่มีดิสทริบิวชันนับร้อยเป็นทั้งภาระ แต่หากใช้ระบบแพ็กเกจและการแจกจ่ายที่มีเอกสารชัดเจน ก็สามารถส่งมอบแอปให้ผู้ใช้ในหลายสภาพแวดล้อมได้
  • GNOME, KDE Frameworks, elementary OS, Electron และ Ubuntu Touch มอบเส้นทางการพัฒนาที่แตกต่างกันด้วย Gtk, Qt, Vala, JavaScript·HTML·CSS และ QML
  • มีช่องทางแจกจ่ายอย่าง AppCenter, AppImage, Flatpak, Open Build Service และ Snapcraft รวมถึงยังมีโอกาสสร้างรายได้ผ่านแอปแบบเสียเงิน บริการ และ app store แบบสนับสนุนผู้พัฒนา

เหตุใด Linux จึงต้องการแอปมากกว่านี้

  • ผู้ใช้ Linux บนเดสก์ท็อปและมือถือมีความต้องการซอฟต์แวร์ใหม่
  • app store และคลังซอฟต์แวร์ของ Linux มีจำนวนแอปพลิเคชันน้อยกว่าแพลตฟอร์มแบบปิด
  • สำหรับผู้หลงใหลในเทคโนโลยี มีการชักชวนให้นำความหลงใหลและความคิดสร้างสรรค์ไปใช้กับแอปพลิเคชันใหม่สำหรับผู้ใช้ Linux แทนการสร้างดิสทริบิวชัน Linux ใหม่เพิ่มขึ้นอีก
  • ข้อความหลักคือ “เลิกสร้าง Linux ดิสทริบิวชัน แล้วมาสร้างแอปพลิเคชันกัน”

ผลของการพัฒนาแอปต่อระบบนิเวศ

  • หากมีไอเดียแอปที่ตัวเองต้องการ ก็อาจมีผู้ใช้อื่นที่มีความต้องการคล้ายกันด้วย
  • หากสร้างแอปพลิเคชันแบบเปิดเผยต่อสาธารณะ นักพัฒนาหน้าใหม่ก็จะได้เรียนรู้และเริ่มต้นได้ง่ายขึ้น ซึ่งช่วยต่อยอดไปสู่การพัฒนาแอป Linux รุ่นถัดไป
  • การพัฒนาแอปพลิเคชันเป็นงานที่ใช้ความคิดสร้างสรรค์ และความรู้สึกสำเร็จเมื่อทำโปรเจ็กต์เสร็จก็อาจเป็นรางวัลได้เช่นกัน
  • การพัฒนาแอปช่วยให้เกิดการรวมตัวของชุมชน และชุมชน Linux ก็มักอยากช่วยให้นักพัฒนาประสบความสำเร็จ
  • ความสามารถด้านการพัฒนาซอฟต์แวร์เป็นทักษะที่มีความต้องการ และยังมีแหล่งเรียนรู้ฟรีจำนวนมาก
  • ความคิดที่ว่าผู้ใช้ Linux ไม่สนับสนุนนักพัฒนาด้านการเงินนั้นเป็นความเข้าใจผิด และยังสามารถสร้างแหล่งรายได้ใหม่จากแอปและบริการแบบเสียเงินที่ได้รับความนิยมได้

การพัฒนาโดยรองรับ Linux ดิสทริบิวชันที่หลากหลาย

  • Linux แตกต่างจากแพลตฟอร์มอื่นตรงที่มีเป้าหมายที่หลากหลายมาก และมีดิสทริบิวชันอยู่หลายร้อยแบบ
  • เมื่อเผยแพร่แอปพลิเคชันแล้ว โดยทั่วไปก็มักจะสามารถทำงานได้ในหลายสภาพแวดล้อม
  • มีระบบแพ็กเกจและการแจกจ่ายที่มีเอกสารครบถ้วน ช่วยให้นักพัฒนาส่งมอบแอปให้ผู้ใช้ได้
  • แต่ละเฟรมเวิร์กสำหรับพัฒนาและแต่ละ Linux ดิสทริบิวชันต่างก็มีแนวทางที่แนะนำในการส่งมอบแอปให้ผู้ใช้
  • เมื่อพร้อมจะแชร์แอปแล้ว สามารถตรวจดูคู่มือแพ็กเกจที่แนะนำได้จากเอกสารสำหรับนักพัฒนา

เส้นทางที่สามารถใช้เริ่มต้นพัฒนาได้

  • GNOME

    • โครงการ GNOME เป็นผู้สร้างเดสก์ท็อป GNOME Shell และรองรับการพัฒนาบนพื้นฐานของ Gjs และ Gtk
    • บน Gtk สามารถใช้ภาษายอดนิยมอย่าง Python, C, C++, Rust และ JavaScript ได้
    • GNOME Developer Center

  • KDE Frameworks

    • KDE มอบทั้งเดสก์ท็อป Plasma และเครื่องมือ·เฟรมเวิร์กสำหรับสร้างแอปพลิเคชัน
    • KDE Frameworks ถูกใช้มาแล้วในการพัฒนาแอปพลิเคชันเดสก์ท็อปที่หลากหลาย
    • โดยหลักใช้ Qt toolkit และภาษาโปรแกรม C++
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OS มุ่งเป็นระบบปฏิบัติการที่รวดเร็ว เปิดกว้าง และเคารพความเป็นส่วนตัว เพื่อใช้แทน Windows และ macOS
    • นักพัฒนาได้สร้างทั้งเดสก์ท็อปและระบบนิเวศสำหรับการพัฒนาแอป
    • คู่มือสำหรับนักพัฒนาแนะนำ Vala และ Gtk
    • elementary OS Developer Guide

  • Electron

    • Electron ช่วยให้สร้างแอปเดสก์ท็อปข้ามแพลตฟอร์มด้วย JavaScript, HTML และ CSS
    • นักพัฒนาสามารถใช้ไลบรารีโมดูล node จำนวนมหาศาลเพื่อสร้างแอปที่อิงเทคโนโลยีเว็บ
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touch เป็นระบบปฏิบัติการโอเพนซอร์สที่ออกแบบให้ทำงานได้บนอุปกรณ์หลากหลาย เช่น โทรศัพท์ แท็บเล็ต และ PC
    • แอปแบบเนทีฟของ Ubuntu Touch สร้างด้วย QML หรือ HTML และกำหนดการทำงานด้วย JavaScript, C++, Python, Rust และ Go
    • Ubuntu Touch Documentation

ความเห็นของนักพัฒนาต่อระบบนิเวศแอป Linux

  • Neil McGovern จาก GNOME Foundation มองว่าหากต้องการพา Linux ไปสู่ผู้ใช้ทั่วไป ก็จำเป็นต้องมีระบบนิเวศแอปที่รุ่งเรือง และทุกคนควรสามารถพัฒนาให้ Linux ได้ เพื่อให้เข้าใกล้เป้าหมายของเดสก์ท็อปแบบเปิด
  • Aleix Pol จาก KDE e.V. กล่าวว่า หากต้องการให้ Linux เป็นระบบปฏิบัติการที่ผู้คนเลือกใช้ ก็ต้องมีแอปที่ยอดเยี่ยม และเครื่องมือพัฒนาก็ช่วยให้สร้างสิ่งที่จินตนาการไว้ได้
  • Daniel Foré ผู้ก่อตั้ง elementary มองว่า ไม่เพียงแต่จะสร้างแอปที่ยอดเยี่ยมบนเดสก์ท็อป Linux ได้เท่านั้น แต่ยังมีโอกาสสร้างplatform API และมีอิทธิพลต่อทิศทางของเดสก์ท็อปด้วย
  • Jan Sprinz กรรมการมูลนิธิ UBports กล่าวว่า การพัฒนาแอปบน Linux แตกต่างจากระบบนิเวศแบบปิดอย่างสิ้นเชิง และแม้จะแข่งขันกันในเชิงเทคนิค ก็ยังร่วมมือกันเพื่อวิสัยทัศน์ที่ใหญ่กว่าได้

วิธีแชร์และแจกจ่ายแอป

  • AppCenter

    • เป็นทั้ง app store แบบเปิดและบริการ build สำหรับนักพัฒนาอิสระ ในรูปแบบ pay-what-you-want
    • AppCenter Dashboard ทำงานร่วมกับ GitHub และรองรับการออกรีลีสกับการติดตาม issue
    • AppCenter Dashboard

  • AppImage

    • สามารถแจกจ่ายแอปพลิเคชันเดสก์ท็อป Linux ในรูปแบบ AppImage เพื่อเข้าถึงผู้ใช้ Linux ดิสทริบิวชันทั่วไปได้
    • ชูแนวคิดแพ็กครั้งเดียวแล้วรันได้ทุกที่
    • AppImage Packaging Guide

  • Flatpak

    • เป็นเฟรมเวิร์กสำหรับการแจกจ่ายแอปพลิเคชันเดสก์ท็อป Linux
    • พัฒนาโดยนักพัฒนาที่ทำงานกับเดสก์ท็อป Linux มายาวนาน และดำเนินงานในฐานะโครงการโอเพนซอร์สอิสระ
    • Flatpak Documentation

  • Open Build Service

    • openSUSE Build Service คืออินสแตนซ์สาธารณะของ Open Build Service
    • ใช้ทั้งในการพัฒนา openSUSE ดิสทริบิวชัน และในการจัดทำแพ็กเกจสำหรับหลายดิสทริบิวชัน เช่น Fedora, Debian, Ubuntu และ SUSE Linux Enterprise จากซอร์สเดียวกัน
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraft เป็นเครื่องมือบรรทัดคำสั่งสำหรับสร้าง snaps
    • snaps ถูกอธิบายว่าเป็นแพ็กเกจแอปสำหรับเดสก์ท็อป คลาวด์ และ IoT ที่ติดตั้งง่าย ปลอดภัย ข้ามแพลตฟอร์ม และไม่มี dependency
    • Snapcraft Documentation

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-11
ความคิดเห็นบน Hacker News

  • ผมคิดว่าสมมติฐานตั้งต้นผิด เพราะ Linux ยังไม่มีชุด เฟรมเวิร์กหลักที่ ABI เสถียร
    แพลตฟอร์มคู่แข่งมีเฟรมเวิร์กพื้นฐานอย่าง CoreImage, CoreAudio, CodeML, SceneKit, AppKit และอื่น ๆ อีกมากกว่า และพังจากการเปลี่ยนแปลงน้อยกว่ามาก
    snap หรือ flatpak ของ Linux ก็น่าสนใจ แต่ใกล้เคียงกับการเลี่ยงไปแก้ด้วยโครงสร้างพื้นฐานและการจัดการแพ็กเกจ มากกว่าจะแก้ในตัวเฟรมเวิร์กและภาษาโปรแกรมที่ขอให้ผู้ใช้ใช้แอปนั้นเอง

    • ชุมชนผู้ชื่นชอบ Linux มักคัดค้านแนวทางแบบนี้อย่างแข็งขัน เพราะต้องการทำให้ทุกอย่างเป็น โมดูลาร์ แล้วประกอบให้เหมาะกับแอปพลิเคชันเฉพาะ
      จริง ๆ แล้ว Linux ก็มีชุดมาตรฐานโดยพฤตินัยอยู่ แต่มีสิ่งที่เปลี่ยนและถูกยกเลิกไป ทำให้เสถียรน้อยกว่า ถึงอย่างนั้นก็ยังดีกว่าที่เห็นจากภายนอก และ Snaps ก็ช่วยบรรเทาปัญหาบางส่วนได้
      แต่ถ้าผู้คนเลือกดิสโทรที่ไม่มีมาตรฐานแบบนั้น เมื่อใดที่คุณไม่รองรับการตั้งค่าแปลก ๆ สารพัดแบบ ก็จะเสียผู้ใช้ที่เป็นไปได้ไปครึ่งหนึ่งทันที
    • เคยอ่านที่ไหนสักแห่งว่าเป้าหมายที่เสถียรที่สุดบน Linux ตอนนี้คือ Win32 ผ่าน Wine หรือ Proton
    • แก่นของเรื่องนั้นคือเฟรมเวิร์ก GNOME หรือ KDE และมาตรฐาน FreeDesktop และอย่างน้อยแผนเมื่อ 20 ปีก่อนก็เป็นแบบนั้น
      แต่ตามที่บทความบอก คนส่วนใหญ่ยังคงโฟกัสกับการทำดิสโทร และโดยธรรมชาติแล้วจึงยากที่จะเกิดสแต็กเดียวที่ไล่ตามดิสโทรแปลก ๆ จำนวนมากได้ทั้งหมด
      สุดท้าย Google ก็นำเคอร์เนล Linux มา แล้ววางชุดเฟรมเวิร์กหลัก 2 ชุดที่ใช้ Java และ JavaScript ทับลงไป และสำหรับผู้บริโภคทั่วไป ดิสโทร Linux เหล่านั้นก็กลายเป็นผู้ชนะ
    • ผมมองว่าความรับผิดชอบหลักอยู่ที่นักพัฒนา glibc การทำอย่าง การใช้ชื่อเวอร์ชันพร่ำเพรื่อ และการเพิ่มชนิด ELF relocation ใหม่เมื่อไม่นานมานี้ ทำให้การแจกจ่ายไบนารีเกมข้ามหลายดิสโทรกลายเป็นเรื่องเจ็บปวด
      โดยทั่วไปนักพัฒนาเกมจะ build บนดิสโทรใหญ่รุ่นล่าสุดแล้วอัปโหลดขึ้น Steam และถ้าดิสโทรนั้นมี glibc 2.36 ไบนารีก็มักจะมีชื่อเวอร์ชันที่บังคับต้องใช้ glibc 2.36 ขึ้นไปตามไปด้วย
      สุดท้ายจึงต้องใช้ directive symver ของ binutils gas เพื่อบังคับให้ชื่อเวอร์ชันเข้ากันได้กับ glibc ที่เก่าพอสมควร โดยส่วนตัวผมมองว่า 5 ปี หรืออาจ 7–8 ปี เป็นเกณฑ์ที่สมเหตุสมผล: https://sourceware.org/glibc/wiki/Glibc%20Timeline
      นักพัฒนาเกมทั่วไปแทบไม่รู้ปัญหาแบบนี้ และต่อให้รู้ ก็คงไม่ยอมทำงานที่เจ็บปวดขนาดนั้นเพื่อส่วนแบ่งตลาด 1% ถ้าเป็น libgcc และ C++ ก็ต้องลิงก์ libstdc++ แบบ static ด้วยจึงจะหลีกเลี่ยงปัญหา ABI นั้นได้
      ถึงอย่างนั้นเอนจิน Godot ก็มี build container ที่คำนึงถึงเรื่องนี้ให้ และฝั่ง Unity ก็ดูเรียบร้อยดี ส่วน UT5.x ผมไม่แน่ใจ
      ในทางกลับกันก็มีเอนจินที่ยังไม่พร้อม เช่น เกมที่ใช้ Electron หากไม่มีเวอร์ชัน GTK+ ที่เข้ากับดิสโทรอย่าง Enlightenment, Qt, X11 ล้วน ๆ หรือ Wayland ก็อาจรันไม่ได้
      การแพ็กเกจเอนจิน Google Blink ทั้งตัวให้ถูกต้องเพื่อแจกจ่ายไบนารีสำหรับดิสโทร ELF/Linux ในวงกว้าง ก็ไม่ใช่เรื่องง่ายเช่นกัน
      โดยรวมแล้ว ELF/Linux ไม่เป็นมิตรกับการแจกจ่ายแบบไบนารีล้วน เพราะ ABI พังกันทั่ว โดยเฉพาะใน SDK และไลบรารีหลัก
      ถ้าไบนารีเกมยังยากขนาดนี้ แอปก็คงยิ่งยากกว่า ภาพที่เห็นคือสุดท้ายนักพัฒนาจะพูดว่า “ไม่สนแล้ว ไปติดตั้ง Microsoft SUSE GNU/Linux ใช้เอาเอง อย่างอื่นไม่รองรับ”
    • ถ้า Linux มีเฟรมเวิร์กหลากหลายระดับเดียวกับที่ macOS มี โปรเจกต์ส่วนตัวของผมก็คงทำให้รองรับ Linux ไปนานแล้ว
      การมีเครื่องมือมากมายที่หยิบมาใช้ได้ทันที โดยแทบไม่ต้องกังวลเรื่องระยะเวลาซัพพอร์ต ว่า fork ไหนดีกว่า หรือจะเข้ากับไลบรารี third-party อื่น ๆ ได้ดีไหม เป็นเรื่องยอดเยี่ยมมาก มันลดแรงเสียดทานลงอย่างมากจนแค่ลงมือสร้างได้เลย
      ระบบนิเวศ KDE Qt และฝั่ง GNOME/GTK ใกล้เคียงที่สุดแล้ว แต่ก็ยังไม่ถึงระดับนั้น

  • อาจเป็นเพราะผมไม่รู้แพตเทิร์นที่ใช้ตัดสินว่าเมื่อไรควรใส่ dev กับ version ในชื่อแพ็กเกจ และเลข 1 หรือ 0 ที่ต่อท้ายแบบสุ่ม ๆ นั้นหมายถึงอะไร แต่ผมคิดว่า Linux distribution ตัวแรกที่มี กฎการตั้งชื่อแพ็กเกจที่สม่ำเสมอ น่าจะชนะใจผู้ใช้ได้
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev ค่อนข้างเข้าใจง่าย เพราะมี header อยู่
      ตัวเลขคือการระบุเวอร์ชันในกรณีที่สามารถติดตั้งหลายเวอร์ชันพร้อมกันได้ แต่ก็อาจมีข้อยกเว้น เช่น xcb1 ที่เป็นส่วนหนึ่งของชื่อไลบรารี
      ตัวอย่างเช่น ณ ช่วงหนึ่งคงเคยสามารถติดตั้ง libgtk-3-0 กับ libgtk-2-$something พร้อมกันได้ และภายหลังแม้จะเอา libgtk-2 ออกไปแล้ว ก็น่าจะยังคงชื่อนั้นไว้เพื่อไม่ให้การอ้างอิง libgtk-3-0 ในบทเรียนเดิม ๆ พัง
      ส่วนเลข 0 ท้าย libwayland-server0 ผมเองก็ไม่แน่ใจเหมือนกัน ผมเห็นไลบรารีเดียวกันใน /var/lib มีหาง .$number หลายแบบ แต่ไม่เคยขุดดูว่ามันแก้ปัญหาอะไรกันแน่
    • การแยก binary กับ source เป็น ธรรมเนียมของ Debian ถ้าแค่ใช้ไลบรารี แพ็กเกจที่ไม่ใช่ -dev ก็พอแล้ว แต่ถ้าจะพัฒนาด้วยไลบรารีนั้น ก็ต้องมี -dev ที่ติดตั้ง header ด้วย
      เลข 1 หรือ 0 ด้านท้ายไม่ได้มีอะไรพิเศษ เป็นแค่ส่วนหนึ่งของชื่อแพ็กเกจหรือเวอร์ชันเท่านั้น
    • ใน Arch และ distribution ลูก ๆ โดยทั่วไปไม่มีอะไรแบบนี้
      แต่ -dev หมายถึงสิ่งที่จำเป็นเฉพาะตอนพัฒนากับไลบรารีนั้น
      ตัวเลขคือหมายเลขเวอร์ชันหลัก หรือก็คือหมายเลขความเข้ากันได้ ทำให้ติดตั้งเวอร์ชันหลักหลายตัวที่แพ็กเกจต่างกันต้องพึ่งพาไว้พร้อมกันได้ง่ายโดยไม่ชนกัน
    • ถ้าจะ build โปรแกรม ก็ติดตั้งแพ็กเกจ -dev ได้เลย โดยปกติไม่ต้องไปสนใจแพ็กเกจ -dev ที่มีเลขกำกับเอง และถ้าจำเป็น แพ็กเกจที่ไม่มีเลขควรเป็นตัวส่งต่อให้
      ระหว่าง build จะมีการบันทึกว่าใช้ suffix หมายเลขใด หรือก็คือ เวอร์ชัน ABI ใด ซึ่งควรตรงกับ suffix .so.N แต่ไม่ได้หมายความว่าต้องไปค้นหาเองด้วยวิธีนั้น
      วิธีนี้ทำให้สามารถติดตั้งสำเนาไลบรารีหลายชุดที่เข้ากันไม่ได้ไว้พร้อมกัน และให้ฝั่งที่เหมาะสมถูกใช้งานได้ โดยปกติ distribution จะเก็บกวาดของเก่า ๆ ในแต่ละ major release
      ตอนติดตั้ง ควรใช้ dependency ที่ถูกบันทึกไว้ระหว่าง build โดยอัตโนมัติ
    • มี GoboLinux อยู่ และในมุมมองของผม มันแก้ได้ทุกอย่างโดยไม่ซับซ้อนเท่า Nix แต่ก็ไม่มีใครสนใจ

  • นี่เป็นหนึ่งในปัญหาใหญ่ที่สุดที่ฉุดแพลตฟอร์ม Linux ทั้งหมดไว้ หลายคนมักพูดว่าเป็นข้อดี แต่ผมไม่มองแบบนั้น
    นักพัฒนามักยกเรื่องมีตัวเลือกเยอะว่าเป็นข้อดีของ Linux แต่สำหรับผู้ใช้จำนวนมาก มันกลายเป็น paradox of choice และทำให้กลับไปใช้แพลตฟอร์มเดิม
    บน macOS และ Windows มีตัวเลือกน้อยกว่า แต่ตัวเลือกที่มีนั้นถูกขัดเกลามากกว่าและกระจัดกระจายน้อยกว่ามาก
    เช่น เราต้องมี tiling window manager กี่ตัวกันแน่? เลือก tiling window manager ที่ดีที่สุด แล้วสร้าง dock กับ applet ที่ดีกว่าไม่ได้หรือ? แล้วแอปกับ launcher ที่ผสานเข้ากับ paradigm ของ tiling window manager ล่ะ?
    แต่แทนที่จะเป็นแบบนั้น หลายครั้งก็เหลือแค่ tiling window manager 10 แบบ กับโปรแกรมแก้ขัดครึ่ง ๆ กลาง ๆ ที่โปะอยู่ข้างบน

    • คนเราไม่ได้วิเคราะห์ตัวเลือกทั้งหมดแบบ exhaustive ก่อนเลือก พวกเขาดูตัวเลือกจำนวนไม่มาก แล้วเลือกสักอย่างตามความนิยมกับความเข้าถึงง่าย
      ecosystem ที่ประสบความสำเร็จจะทำให้แม้เลือกตัวเลือกที่เด่นชัด ก็ได้ผลลัพธ์ที่ดีพอ
      การมี Linux distribution เพิ่มขึ้นส่วนใหญ่เป็นแค่ความแตกต่างเล็ก ๆ ที่ไม่ได้ลดความเหมาะสมอย่างมีนัยสำคัญ และมีเพียงคนส่วนน้อยมากที่เดิมก็ไม่ลำบากกับการเลือก distribution อยู่แล้วที่มองว่าเป็นปัญหา
      ในทางกลับกัน กรณีอย่าง Wayland กลายเป็นปัญหาจริง เพราะส่วน plumbing กับ hardware จู่ ๆ ก็สำคัญขึ้นมา และถ้าจะเลือกชุดผสมที่ใช้งานได้ดี ก็ต้องรู้โครงสร้างภายในอยู่บ้าง
      การเอา Mac หรือ Windows มาเทียบกับ Linux ก็ไม่ค่อยมีความหมาย สำหรับผู้บริโภค 95% ระบบปฏิบัติการเป็นคุณสมบัติหรือฟังก์ชันที่ติดมากับคอมพิวเตอร์ ไม่ใช่ผลิตภัณฑ์แยกต่างหาก
      ถ้าแพ็กเกจโดยรวมตรงใจ พวกเขาอาจซื้อคอมพิวเตอร์ที่ติดตั้งระบบปฏิบัติการนั้นมา แต่จะไม่พยายามเอาไปติดตั้งเองบนเครื่อง Windows หรือ Mac ของตัวเอง
      คนที่มีความรู้ทางเทคนิคมากพอจนพอใจได้ คงไม่สับสนมากนักแม้จะมี Ubuntu derivative เพิ่มมา 3 ตัวกับ Arch derivative เพิ่มมา 2 ตัว
    • การทำ tiling window manager นั้นสนุก การร่วมมือกันทำซอฟต์แวร์ไม่ได้เป็นแค่วิธีไปสู่ผลลัพธ์บางอย่าง แต่เป็นเป้าหมายในตัวมันเองด้วย
      การเป็นนักพัฒนาโอเพนซอร์สหมายถึงการกำหนดเป้าหมายและวิธีการได้เอง ซึ่งในการพัฒนาซอฟต์แวร์เชิงพาณิชย์มักไม่มีเสรีภาพแบบนั้น
      มันอาจมีส่วนหยาบ ๆ บ้าง แต่ IKEA effect ทำงาน แล้วสุดท้ายก็จะชอบมัน
    • ปัญหานี้เป็นเรื่องที่ distribution ควรแก้ คนที่ไม่อยากมีตัวเลือกเยอะก็ใช้ distribution ที่ตัดสินใจแทนให้หลายอย่างได้ ไม่จำเป็นต้องผลักดันให้ตัดตัวเลือกออกจากทั้ง ecosystem
      ถ้าทุกคนใช้ซอฟต์แวร์เดียวกันหมด ก็จะกลายเป็น ecosystem แบบปลูกพืชเชิงเดี่ยว ที่เปราะบางต่อการโจมตีมากขึ้น เหตุผลที่ Windows ตกเป็นเป้าไวรัสบ่อยก็เพราะเป้าหมายใหญ่และมีความสม่ำเสมอ
      ถ้าเจาะเครื่อง Windows ของผู้ใช้ทั่วไปได้เครื่องหนึ่ง เครื่องอื่น ๆ ก็มักเจาะได้คล้ายกัน แต่ถ้าเล็ง Linux จะยากกว่ามาก
      อีกอย่าง นี่คือซอฟต์แวร์เสรี ถ้าไม่ได้จ่ายเงินจ้างใคร ส่วนใหญ่ก็คืองานอาสาสมัคร และเราไปสั่งไม่ได้ว่าคนอื่นควรใช้เวลาอาสาของเขากับอะไร
      ทั้งที่มีกลุ่มอยู่มากมายขนาดนี้ แต่ถ้ายังไม่มีใครอยากเข้าร่วม ก็ควรหันกลับมาดูโครงสร้างทางสังคมที่ครอบงำอยู่ด้วย การเริ่มจากเลิก code of conduct ที่ทำให้ลงโทษพฤติกรรมนอกโปรเจกต์ได้ อาจเป็นจุดเริ่มต้นหนึ่ง
    • ผมว่ามี launcher กับ dock มากกว่า tiling window manager เสียอีก
      และผมก็ไม่ค่อยรู้ว่าควรปรับปรุงอะไรให้ดีขึ้นอีก ของอย่าง Ulauncher หรือ Albert นั้นทรงพลังกว่าสิ่งที่ทำได้บนแพลตฟอร์มอื่นมาก และผมก็ไม่รู้ว่าจะทำ UI ให้ดีกว่านี้ได้อย่างไร
    • มี tiling window manager เท่าที่ผู้คนอยากสร้างก็พอ

  • การมีซอฟต์แวร์มากขึ้นเป็นเรื่องดี แต่ก่อนจะสร้างใหม่ตั้งแต่ต้น ผมคิดว่าน่าจะลองมีส่วนร่วมกับสิ่งที่มีอยู่แล้ว หรือเลือกโปรเจกต์ที่ถูกทิ้งร้างหรือจำเป็นต้องปรับแต่งให้บิลด์และรันได้บนคอมไพเลอร์กับฮาร์ดแวร์รุ่นใหม่ ๆ ดูก่อน
    ก็สงสัยเหมือนกันว่ามี ฐานข้อมูลโปรเจกต์ที่พักไว้/ตายไปแล้ว ที่ควรค่าแก่การชุบชีวิตอยู่ที่ไหนสักแห่งหรือไม่

    • สิ่งที่มีอยู่แล้วอาจไม่ได้ถูกสร้างมาในแบบที่ผมตั้งเป้าไว้
      อีกโปรเจกต์หนึ่งอาจนำโดยคนที่ทำงานด้วยยาก หรือเป็นชุมชนที่ไม่รับข้อเสนอและแพตช์
      ขั้นตอนทางสังคมและอุปสรรคต่าง ๆ อาจทำให้หมดแรงจูงใจในการมีส่วนร่วม ไม่ใช่ทุกคนจะเป็นทีมเพลเยอร์มองโลกในแง่ดีแบบไม่มีอีโก้ได้
      สำหรับผม การเริ่มใหม่ตั้งแต่ต้นดีกว่า เพราะควบคุมตัวแปรทั้งหมดได้ ไม่ต้องไปแตะโครงสร้างพื้นฐานทางสังคม/เทคนิคเดิม ไม่ต้องโน้มน้าวใครว่าไอเดียของผมดี และไม่อยากใช้เวลากับการโต้แย้งและถกเถียงมากกว่าเขียนโค้ด
      ประสบการณ์แบบ พัฒนาเดี่ยว ดีกว่าสำหรับผม เพราะไม่ถูกผูกมัดกับการเมืองและขั้นตอนทางสังคม และการพยายามเป็นทีมเพลเยอร์มีแต่ทำให้ผมเจ็บปวด
    • ในสาขาส่วนใหญ่มีความพยายามที่คุณภาพต่ำมากเกินไป และถ้ารวมแรงเหล่านั้นไปไว้ในโปรเจกต์ชั้นนำไม่กี่ตัว ก็น่าจะได้แอปดี ๆ ออกมาหลายตัว
      การร่วมมือกันอาจดูเป็นภาระและยากลำบาก แต่สุดท้ายมันคือการทำให้เกิดผลลัพธ์ และเป็นการใช้เวลาที่ดีกว่าการทุ่มให้โปรเจกต์ที่จะถูกทิ้ง
    • สงสัยว่ามีที่ไหนในบรรดาคลังแพ็กเกจ Linux หลัก ๆ ที่รวบรวมสถิติให้ค้นหา แอปที่มีคนใช้มากแต่ไม่ได้รับการดูแลหรือฟีเจอร์ยังไม่สมบูรณ์ ได้หรือไม่

  • มีคนบ่นกันมากว่าเครื่องมือสำหรับสร้างแอปที่เข้ากันได้หลายระบบปฏิบัติการยังไม่พอ แต่ผมไม่เห็นด้วย แค่มองทางเลือกที่ไม่ใช่ Electron ก็มีแล้ว
    Telegram ใช้ Qt เพื่อแจกจ่ายแอปเนทีฟประสิทธิภาพดีบนทั้งสามระบบปฏิบัติการ
    Flutter คอมไพล์เป็นโค้ดเนทีฟได้บนทั้งสามระบบปฏิบัติการและมือถือ
    Kirigami เป็นเฟรมเวิร์ก QtQuick ที่ช่วยให้สร้างแอปที่รันได้ทั้งบนมือถือและเดสก์ท็อปทุกเป้าหมาย
    ก็แค่สร้างแอปขึ้นมา ไม่มีเหตุผลต้องใช้เรื่องนี้เป็นข้ออ้างในการตำหนิ Linux

    • Flutter ทำงานต่างกันเล็กน้อยในแต่ละแพลตฟอร์ม จึงให้ประสบการณ์ที่แย่แบบละเอียดอ่อนบนทุกแพลตฟอร์ม ส่วน Kirigami หรือ Qt Quick ก็ยากจะมองว่าเป็นตัวเลือกที่ใช้ได้จริง
      บน Windows, macOS และมือถือ แทบไม่มีชุมชนหรือโปรเจกต์จริงจังเลย ไม่ได้ตั้งใจจะด้อยค่าฝั่ง KDE แต่ความจริงเป็นแบบนั้น
      ไลเซนส์ของ Qt Quick บน iOS ก็ไม่ง่าย หรือถ้าไปทางเชิงพาณิชย์ก็แพงมาก
      ในทางกลับกัน Electron มีบริษัทใหญ่ ๆ ลงทุน ทำให้มี เครื่องมือระดับโปรดักชัน ที่ขัดเกลามาอย่างดี มีชุมชนขนาดใหญ่และระบบนิเวศไลบรารีมหาศาล และก็ไม่ใช่ภาษาที่ไม่คุ้นอย่าง Dart
      Telegram พยายามไปอีกระดับจริง ๆ ไคลเอนต์ทำออกมาได้ยอดเยี่ยม
    • แอป Telegram ที่ใช้ Qt ก็รันบน macOS ได้ดี แต่ผู้ใช้ Apple ส่วนใหญ่เลือก ไคลเอนต์ Swift/Cocoa สำหรับ macOS และ iOS[0]
      [0]: https://github.com/overtake/TelegramSwift

  • ปัญหาอยู่ที่ซอฟต์แวร์ OSS แทบไม่แม้แต่จะพยายามแข่งขันกับตลาด
    คนที่ใช้ซอฟต์แวร์ OSS มักยอมรับเป็นเรื่องปกติว่า UX จะขาด ๆ เกิน ๆ และในความเป็นจริงก็มักเป็นแบบนั้น
    ซอฟต์แวร์ proprietary ทั่วไปต้องปรับตัวให้ประสบการณ์ของผู้ใช้ปลายทางดีขึ้น เพราะมีความเสี่ยงที่ผู้ใช้จะไม่จ่ายเงิน แต่ OSS มักไม่มีความเสี่ยงแบบนั้น โอเพนซอร์สก็จำเป็นต้องเผชิญความเสี่ยงที่มาจากผู้ใช้ปลายทางด้วย
    เคยพยายามเปลี่ยนสิ่งนั้นด้วย Notes[1] แต่ก็รู้สึกว่าการอยู่ได้ด้วยโฆษณาอย่างเดียวนั้นยาก เคยลองใส่การจ่ายเงินสำหรับฟีเจอร์พรีเมียมอย่าง Kanban ด้วย แต่แอปเป็น FOSS เต็มรูปแบบ ใคร ๆ ก็สามารถคอมไพล์จากซอร์สได้ง่าย ๆ
    แอปถัดไป[2] คิดว่าจะทำเป็น ซอร์สปิด ก่อนเปิดตัว ผมรับความเสี่ยงที่ความพยายามของตัวเองจะไม่ได้รับผลตอบแทนไม่ไหว
    ถ้าสามารถเก็บเงินได้ ก็จะลงทุนกับแอปที่เน้น UX บน Linux ได้มากขึ้น จึงเชื่อว่านี่เป็นประโยชน์ต่อชุมชน Linux ด้วย บางส่วนอาจเปิดเป็นโอเพนซอร์ส และในอนาคตไกล ๆ อาจเปิดทั้งหมดก็ได้
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • ผู้ใช้ Linux กับคนที่ให้คุณค่ากับเสรีภาพมีส่วนทับซ้อนกันมาก สำหรับหลายคน แอปจดโน้ตที่ไม่ใช่โอเพนซอร์สไม่ใช่ตัวเลือกตั้งแต่แรก เพราะมีปัญหาเรื่อง การผูกติดกับผู้ขาย และความเป็นส่วนตัว
      ดังนั้นถ้าไม่ทำโปรแกรมเป็นโอเพนซอร์ส ก็มีโอกาสเสียมากกว่าการทำเป็นโอเพนซอร์สแล้วรับความเสี่ยงว่าบางคนจะไม่จ่ายเงิน
      ผมคิดว่ามีคนที่ยอมจ่ายเงินเพื่อใช้โอเพนซอร์สมากกว่าคนที่อยากใช้ซอฟต์แวร์ proprietary อยู่มาก
      การเป็นโอเพนซอร์สไม่ได้แปลว่าต้องแจกจ่ายโค้ดให้ทุกคน และถ้าเก็บเงิน ก็อาจให้ซอร์สโค้ดเฉพาะผู้ใช้ที่จ่ายเงินเท่านั้นได้ เพียงแต่พวกเขาจะมีสิทธิ์แก้ไขและเผยแพร่ต่อ
      ถ้าไม่สนใจโอเพนซอร์ส ก็ใช้ Notion หรือ Evernote ได้ ถ้ากำลังหาแอปจดโน้ตโอเพนซอร์สรุ่นใหม่ ๆ ขอแนะนำ Logseq
    • ดูเหมือนกำลังตัดสินใจถูกแล้ว การหาเงินจากโอเพนซอร์สให้พอเลี้ยงชีพนั้นยากอย่างยิ่ง และมีขนาดเล็กกว่าคนที่ทำมาหากินด้วยซอฟต์แวร์เชิงพาณิชย์อยู่หลายหลัก
    • เข้าใจความอึดอัดนะ แต่ก็มีตัวอย่างแย้งอยู่ ไม่ได้ตั้งใจจะดูถูก
      อย่างแรก Notes ดูค่อนข้างคล้ายกับ Standard Notes ถ้าสร้าง Notes โดยใช้ OSS แบบ copyleft ผมคิดว่าก็คงบ่นได้ยาก เว้นแต่จะจ่ายค่าลิขสิทธิ์ให้ผลงานของโปรแกรมเมอร์คนอื่น ๆ ที่รวมอยู่ในนั้นด้วย
      อย่างที่สอง ผมคงเป็นผู้ใช้ที่ไม่ค่อยปกติ ใช้ Linux มานานกว่า 20 ปี แต่ยังเขียน Bash script หรือ Perl สักบรรทัดให้ดีไม่ได้เลย
      แต่เพราะผมเขียนโค้ดไม่ได้ และรู้สึกขอบคุณงานของคนอื่นกับเสรีภาพที่มันมอบให้ ผมจึงใช้เงินกับซอฟต์แวร์มากกว่าที่คนทั่วไปบนแพลตฟอร์มอื่น ๆ มักใช้กันมาก
      ผมสนับสนุนหลายที่ เช่น Kaisen และ Debian, ยูทิลิตี้หลักของ FSF กับ Emacs, KDE, Firefox ของ Mozilla, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek และบริการอย่าง envs.net
      บางอย่างจ่ายรายปี บางอย่างจ่ายรายเดือน บางอย่างจ่ายครั้งเดียว
      ตอน Standard Notes ออกมาแรก ๆ ก็สมัครสมาชิก 7 ปี แต่ใช้ไปประมาณสองเดือนแล้วไม่พอใจจึงเลิกไป บางอย่างอย่าง Alacritty ผมใช้เยอะ แต่หาวิธีบริจาคไม่เจอ และพยายามทำให้กรณีแบบนั้นมีให้น้อยที่สุด
    • โดยส่วนตัวคิดว่า KDE นำหน้า macOS และ Windows ไปไกลมาก
      ที่จริงรู้สึกว่า macOS เป็นหนึ่งในตัวจัดการหน้าต่างที่แย่ที่สุดในบรรดาแพลตฟอร์มยอดนิยม มันสวยและใช้ง่ายก็จริง แต่ถ้าจะทำอะไรที่เกินพื้นฐาน ก็ต้องใช้คาถาวิเศษที่ค้นพบเองตามธรรมชาติไม่ได้
      แน่นอนว่าเรื่องรสนิยมแต่ละคนไม่เหมือนกัน
    • มีความคิดอยู่สองสามอย่าง แม้ผมจะค่อนข้างติดตามสายนี้ แต่ก็ไม่เคยได้ยินแอปนั้นมาก่อน และการแข่งขันก็รุนแรงสุด ๆ
      ผมคลิกเข้าไปดูราคาพรีเมียมแล้ว ถ้าคิดเป็นรายปีก็สมเหตุสมผล แต่เห็นมีแค่ตัวเลือกสมัครสมาชิกรายเดือน เลยรู้สึกว่ายาก
      สำหรับแอปแบบนี้ ผมมีแนวโน้มจะบริจาคมากกว่าจ่ายเงินเพื่อเวอร์ชันพรีเมียม Obsidian ใช้โมเดลนั้นได้ผลดี
      ผมไม่คิดว่าการเข้าถึงฟีเจอร์ก่อนใครมีคุณค่ามากนัก แต่มีคนจำนวนมากที่จ่ายเงินเพื่อสนับสนุนงาน
      อีกอย่าง โครงสร้างที่มีระบบนิเวศโอเพนซอร์สขนาดใหญ่อยู่รอบผลิตภัณฑ์แกนหลักที่ปิด ผมคิดว่าช่วยสร้างเหตุผลให้คนยอมจ่ายเงินได้

  • ถ้าในบทความมีตัวอย่างสักสองสามอย่างก็คงดี
    ผมนึกไม่ค่อยออกว่าคนที่กำลังสร้าง distro แต่จริง ๆ แล้วควรสร้างแอปพลิเคชันคือใคร ถ้าฝืนคิดก็คงประมาณ LinuxCNC? แต่นั่นมีข้อกำหนดเฉพาะด้านเคอร์เนล จึงอาจเหมาะกับ distro แบบปรับแต่งเองมากกว่า

    • desktop environment แท้จริงแล้วก็เป็นแอปพลิเคชันที่ติดตั้งได้ง่ายด้วยการคลิกหรือคำสั่งหนึ่งสองครั้ง
      ผมไม่ค่อยเข้าใจ distro ที่แตกแขนงต่อจาก distro ที่แตกแขนงอีกที เพียงเพื่อใส่ desktop environment แบบอื่นแล้วแจกจ่าย

  • แทนที่จะบอกว่า “เลิกทำ Linux distro แล้วไปทำแอปพลิเคชันเถอะ” ผมคิดว่าควรเลิกฟังคนที่พยายามสั่งว่าควรทำอะไรและไม่ควรทำอะไรมากกว่า

    • ผมก็รู้สึกขัดใจกับน้ำเสียงนั้นเหมือนกัน
      แต่สารและข้อมูลเองก็ดี
      โดยส่วนตัวผมน่าจะพูดประมาณว่า “ผู้ใช้ Linux ไม่ได้อยากได้ distro เพิ่ม พวกเขาอยากได้ซอฟต์แวร์” อย่างน้อยสำหรับผมก็เป็นแบบนั้น
    • ก็ควรเลิกฟังคนที่บอกให้เลิกฟังคนที่พยายามสั่งว่าควรทำอะไรและไม่ควรทำอะไรด้วยเหมือนกัน ไม่ใช่ว่าทุกอย่างเป็นเรื่องสัมพัทธ์ไปหมด มันมีตัวเลือกที่ดีและตัวเลือกที่แย่อยู่

  • ช่วงหลังย้ายจาก Mac มาใช้ Linux เพราะอยากใช้เครื่องมือสองที่ประสิทธิภาพดีเป็น เครื่องใช้งานประจำวัน
    ก่อนหน้านี้ก็เคยติดตั้ง Linux บนหลายเครื่องมาแล้ว แต่ครั้งนี้ไม่ใช่แค่งานอดิเรก
    Ubuntu รองรับฮาร์ดแวร์และอุปกรณ์ต่อพ่วงของฉันได้ดี แต่ App Store ยังไม่สมบูรณ์และให้ความรู้สึกเหมือนถูกยัดเข้ามาแบบฝืน ๆ ถึงอย่างนั้นแทบทุกอย่างก็ทำงานได้ตามที่คาดไว้
    อยากลองดู Mint, Debian, Arch ด้วย แต่ก็ระวังอยู่ เพราะดูเหมือนมีซอฟต์แวร์จำนวนมากที่เขียนโดยคำนึงถึง Ubuntu

    • Linux Mint มีพื้นฐานจาก Ubuntu จึงใช้แพ็กเกจของ Ubuntu ได้โดยไม่มีปัญหา จริง ๆ มองว่าเป็น Ubuntu ที่ดีกว่าก็ได้
      มี Mint เวอร์ชันที่มีพื้นฐานจาก Debian ด้วย แต่เวอร์ชันนั้นออกแนวเป็นมาตรการสำรองเพื่อไม่ให้พึ่งพาฝั่ง Ubuntu อย่างหนักจนเป็นจุดเสี่ยง
      ทุกวันนี้ต่อให้ใช้ดิสโทรที่แปลกออกไปก็ไม่ค่อยมีปัญหาใหญ่ เพราะถ้า package manager หลักไม่มีแอปที่ต้องการ ก็ใช้ AppImage, Flatpak, Snap ได้
    • ของที่เขียนมาสำหรับ Ubuntu แล้วจะรันบน Arch หรือดิสโทรสมัยใหม่ส่วนใหญ่ไม่ได้ แทบไม่มีเลย
      ตอนใช้ Arch ต้องชินกับสมมติฐานที่คนมักยึด Ubuntu เป็นเกณฑ์ แต่ส่วนใหญ่ก็แค่แพตช์ไฟล์ตั้งค่าหรือตั้ง environment variables เท่านั้น
      เรื่องพวกนั้นเป็นทักษะที่มีประโยชน์และนำไปใช้ที่อื่นต่อได้
    • Fedora ก็ควรลองใช้สักครั้ง
      คิดว่าน่าจะได้ลองใช้เร็วกว่านี้

  • ไม่เข้าใจว่าทำไมใครถึงจะทำแบบนั้น มันยากกว่า และผู้ใช้ Linux จะไม่จ่ายเงินให้สิ่งที่ไม่คุ้มค่าจะจ่าย

    • เพราะโลกจะได้ประโยชน์ถ้ามี ซอฟต์แวร์ฟรี ดี ๆ มากขึ้น