แชตยูนิกซ์แบบเรียบง่าย

 (the-dam.org)
3 คะแนน โดย GN⁺ 2023-07-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • suc คือ Simple Unix Chat ที่นำฟังก์ชันแกนหลักบางส่วนของแชตสไตล์ Slack·Mattermost มาสร้างด้วยการผสม องค์ประกอบพื้นฐานของ UNIX กับ Bash โดยลูปหลักมีเพียง 5 บรรทัด แต่สคริปต์จริงยาวกว่านั้น
  • ข้อความจะถูกอ่านทีละบรรทัดจาก standard input จากนั้นเติมวันที่และชื่อผู้ใช้ แล้วเพิ่มต่อท้ายลงในไฟล์ช่องทางของ /var/lib/suc/ ส่วน การยืนยันตัวตนและการควบคุมสิทธิ์ ปล่อยให้ SSH และโมเดลสิทธิ์ของ UNIX จัดการ
  • ต่างจากเซิร์ฟเวอร์ Mattermost ที่มีโค้ด Go เพียงอย่างเดียวราว 500,000 บรรทัด suc เน้นว่าโค้ดที่เล็กกว่ามากก็สามารถสร้างพฤติกรรมแกนหลักที่คล้ายกันได้
  • usuc ใช้การผสาน tail -f, rlwrap, pygmentize และคำนำหน้าคำสั่ง : เพื่อจัดการ การอ่านช่องทาง, การแสดงผลสไตล์ Markdown และการแชร์ผลลัพธ์ของคำสั่ง
  • เพราะช่องทางเป็นเพียงไฟล์ข้อความธรรมดา จึงเชื่อมต่อกับเครื่องมือ UNIX อย่าง grep, tail, bat, lnav, Git hook และสคริปต์บอตได้ง่าย

ความซับซ้อนที่ suc พยายามลดลง

  • suc ย่อมาจาก Simple Unix Chat มีฟังก์ชันน้อยกว่า Slack, Mattermost และ IRC และแม้จำนวนบรรทัดทั้งหมดจะเกิน 5 บรรทัด แต่ ลูปแกนหลัก สำหรับเขียนข้อความประกอบด้วย Bash 5 บรรทัด
  • ฟีเจอร์เป้าหมายคือแชต rich text แบบเรียลไทม์, การแชร์ไฟล์, การควบคุมการเข้าถึงแบบละเอียด, ระบบอัตโนมัติและการเชื่อมกับเครื่องมือภายนอก, การเข้ารหัสระหว่างส่ง, การเข้ารหัสตอนเก็บข้อมูลแบบเลือกได้ และการยืนยันตัวตนผู้ใช้
  • การทำให้มีขนาดเล็กเป็นไปได้เพราะอาศัย องค์ประกอบพื้นฐานที่สอดคล้องและนำมาประกอบกันได้ ซึ่งมีอยู่แล้วในระบบ UNIX สมัยใหม่
  • เมื่อเทียบกับเซิร์ฟเวอร์ Mattermost ที่มีโค้ด Go ราว 500,000 บรรทัด ผู้เขียนมองว่า suc สามารถทำฟังก์ชันแกนหลักของ Mattermost ได้ด้วยโค้ดเพียง 0.005% ของจำนวนนั้น

ลูปเขียนข้อความ 5 บรรทัด

  • ลูป Bash หลักของ suc จะอ่านทีละบรรทัดจาก standard input เติมวันที่และชื่อผู้ใช้จริง แล้วเพิ่มต่อท้ายลงในไฟล์ /var/lib/suc/"$1"
  • สคริปต์จริงยาวกว่านี้เพราะมีการ preprocess เพื่อความปลอดภัยและการคำนวณสีของชื่อผู้ใช้ แต่การทำงานหลักในการเขียนบันทึกแชตสรุปได้ 3 ข้อ
    • อ่านทีละบรรทัดจาก standard input
    • เติมวันที่และชื่อผู้ใช้จริง
    • เพิ่มต่อท้ายลงในไฟล์ช่องทางใต้ /var/lib/suc/
  • การยืนยันตัวตน, การควบคุมการเข้าถึง, การเข้ารหัส และ rich text ไม่ได้ทำโดยโค้ดภายใน suc แต่เป็นหน้าที่ของ SSH, API ควบคุมการเข้าถึงของ UNIX และความเป็นโมดูลแบบข้อความ

SSH รับหน้าที่การยืนยันตัวตน

  • โปรเซส suc ทำงานโดยผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว ดังนั้น suc เองจึง ไม่มีโค้ดสำหรับยืนยันตัวตน
  • การยืนยันตัวตนระยะไกลจัดการโดย ssh เช่นเดียวกับเซิร์ฟเวอร์ UNIX ทั่วไป
    • shared secret อย่างรหัสผ่าน
    • cryptographic challenge
    • อุปกรณ์สร้างรหัสผ่านใช้ครั้งเดียว (OTP)
    • MFA ที่ผสมหลายวิธีเข้าด้วยกัน
  • ssh ยังยืนยันตัวตนของเซิร์ฟเวอร์ให้ไคลเอนต์ด้วยเพื่อป้องกันการโจมตีแบบ man-in-the-middle และเข้ารหัสข้อมูลทั้งหมดระหว่างไคลเอนต์กับเซิร์ฟเวอร์
  • การติดตั้ง suc ขึ้นอยู่กับโฮสต์ UNIX และการตั้งค่าเซิร์ฟเวอร์ ssh
    • ผู้ใช้ต้องมีอยู่ในระบบ
    • เซิร์ฟเวอร์ ssh ต้องอนุญาตให้ผู้ใช้นั้นล็อกอินจากระยะไกลได้
  • ใน GNU Guix สามารถเพิ่มผู้ใช้และ SSH key ได้ในบรรทัดเดียวด้วยการตั้งค่าแบบ declarative และถ้าบรรทัดตั้งค่านั้นหายไป ผู้ใช้ก็จะถูกลบออกระหว่างขั้นตอน reconfigure

โมเดลสิทธิ์ของ UNIX รับหน้าที่ควบคุมการเข้าถึง

  • suc ไม่เพียงไม่มีโค้ดยืนยันตัวตน แต่ยังไม่มีโค้ดควบคุมการเข้าถึงด้วย และเรียกแนวทางนี้ว่า security agnosticism
  • เคอร์เนล UNIX รู้จักผู้ใช้, กลุ่ม, โปรเซส และไฟล์ และจะตัดสินสิทธิ์อ่าน-เขียนไฟล์จาก effective owner ของโปรเซส
  • ไฟล์ช่องทางใน /var/lib/suc เป็นของผู้ใช้ suc และตั้งค่าให้ผู้ใช้สามารถอ่านบางช่องทางได้ผ่านสิทธิ์อ่านระดับกลุ่ม
  • ผู้ใช้ทั่วไปจะไม่เขียนไฟล์โดยตรง แต่เรียกใช้ suc แทน ส่วนการจับคู่สิทธิ์และการปฏิเสธการเข้าถึงเป็นหน้าที่ของเคอร์เนล
  • ในชุมชนที่ต้องการข้อจำกัดมากขึ้น สามารถมีไบนารี setuid แยกตามกลุ่มได้
    • ตัวอย่างเช่น suc_blue เป็นของผู้ใช้ blue และให้รันได้เฉพาะกลุ่ม blue
    • ผู้ใช้ในกลุ่ม blue สามารถเขียนลงช่องทาง blue ผ่าน suc_blue ได้
    • ผู้ใช้กลุ่ม red จะอ่านหรือเขียนช่องทาง blue ไม่ได้
  • สคริปต์ช่วยสร้างช่องทาง suc_channel.sh ยาวประมาณ 80 บรรทัด และผู้ใช้ GNU Guix สามารถสร้างไบนารี setuid, ผู้ใช้, กลุ่ม และไฟล์ช่องทางที่จำเป็นได้ด้วยบรรทัดเดียว (suc-private-channel "red" "red")
  • transactional update ของ GNU Guix รับประกันว่าการเปลี่ยนแปลงค่าตั้งจะถูกนำไปใช้ครบทั้งหมดหรือไม่ถูกใช้เลย และสามารถ rollback กลับไปยังสถานะการทำงานก่อนหน้าได้

Rich text และ usuc

  • แอปแชตจำนวนมากเรนเดอร์ข้อความด้วยเอนจิน HTML และไคลเอนต์เดสก์ท็อปของ Mattermost ใช้ Electron
  • suc ใช้ไฟล์ข้อความหนึ่งไฟล์ต่อหนึ่งช่องทาง และผู้ใช้สามารถดูได้ด้วยเครื่องมือบรรทัดคำสั่งอย่าง tail หรือ cat
  • หากใช้ ANSI escape code ของเทอร์มินัลร่วมกับการรองรับ UTF-8 ก็สามารถสร้างประสบการณ์คล้าย rich text ทั้งสี, อีโมจิ และรูปแบบพื้นฐานได้
  • suc ทำหน้าที่เพียงเขียนลงไฟล์ช่องทาง ส่วนการอ่านเป็นหน้าที่ของ usuc
    • suc เป็นไบนารีที่มีสิทธิ์พิเศษ จึงควรลด logic และ dependency ภายนอกให้น้อยที่สุด
    • usuc ทำงานด้วยสิทธิ์ของผู้ใช้ที่เรียก จึงเพิ่มความสามารถต่าง ๆ ได้อย่างอิสระกว่า
  • usuc ทำหน้าที่เป็นไคลเอนต์แชตโดยร้อยเรียงเครื่องมือเล็ก ๆ หลายตัวเข้าด้วยกัน
    • ใช้ rlwrap เพื่อให้มี history และการแก้ไขบรรทัด
    • เลือกไบนารี suc แบบ setuid ที่เหมาะสมตาม owner ของไฟล์ช่องทาง
    • ใช้ tail -f -n 20 เพื่อแสดง 20 บรรทัดล่าสุดและบรรทัดที่เพิ่มเข้ามาหลังจากนั้น
    • ตรวจสอบว่าบรรทัดอินพุตขึ้นต้นด้วย : หรือไม่
    • ส่งข้อความที่ผู้ใช้ป้อนผ่าน pygmentize
  • pygmentize จะมอง standard input เป็น Markdown และแสดงผลเป็นข้อความสี ANSI ดังนั้นมาร์กอัปอย่าง **bold** จึงรองรับได้ด้วยโค้ดเพียงบรรทัดเดียว

คำสั่งแชตและการผสานกับเชลล์

  • usuc จะไม่ส่งข้อความเป็นข้อความธรรมดาหากขึ้นต้นด้วย : แต่จะรันคำสั่งนั้นแล้วส่ง ผลลัพธ์ที่แสดงออกมา ไปยัง suc
  • ตัวอย่างเช่น หากรัน gum style --border=rounded --bold --foreground=#F00 "Hello World !" ข้อความพร้อมเส้นขอบและสไตล์จะปรากฏในช่องทาง
  • คำสั่งจะทำงานใน namespace ของผู้ใช้ที่เรียก usuc ดังนั้นผู้ใช้แต่ละคนจึงมีมาโครแชตของตัวเองได้โดยไม่กระทบคนอื่น
  • ที่ the dam มีการใช้สิ่งนี้ระหว่างเล่น tabletop RPG เพื่อทอยลูกเต๋าด้วยคำสั่งอย่าง roll 2d6

text pipe และการเชื่อมกับเครื่องมือภายนอก

  • ผู้ใช้สามารถไม่ใช้ฟังก์ชันรันคำสั่งของ usuc แล้ว pipe เอาผลลัพธ์ของคำสั่งจากเชลล์เข้า suc โดยตรงได้
  • หากส่งผลลัพธ์แบบมีสีของ bat เข้า suc ก็สามารถแชร์โค้ด snippet พร้อม syntax highlighting ลงในช่องทางได้
  • make test > testlog || (suc devops < testlog ; exit 1) เป็นตัวอย่าง one-liner ของ Bash สำหรับส่ง log ไปยังช่องทาง devops เมื่อการทดสอบล้มเหลว
  • one-liner นี้สามารถใส่ไว้ใน hook update ของ Git repository เพื่อรันทดสอบตอน push และหากล้มเหลวก็ปฏิเสธการอัปเดตพร้อมแจ้งทีม DevOps ได้
  • งานที่เทียบได้กับฟังก์ชัน integration ของ Slack หรือ Mattermost สามารถประกอบขึ้นได้ด้วย text pipe และสคริปต์ของ UNIX

การอ่านช่องทาง, การแจ้งเตือน, บอต

  • ช่องทางของ suc เป็นไฟล์ข้อความที่อัปเดตต่อเนื่อง จึงสามารถอ่านบรรทัดใหม่ด้วย tail -f แล้วนำไปประมวลผลต่อได้
  • เมื่อมีข้อความใหม่เข้ามา สามารถสร้าง pipeline ที่เรียก notify-send เพื่อแจ้งเตือนได้ และใช้ grep กรองเฉพาะชื่อหรือคีย์เวิร์ดอย่าง “build failure” ได้
  • หากต้องการรวมหลายช่องทางไว้ในฟีดเดียว สามารถใช้ tail -f /var/lib/suc/*
  • เมื่อใช้ lnav จะได้ความสามารถอย่างการจำตำแหน่งที่อ่าน, bookmark, สีแยกตามช่องทาง, การ parse วันที่·ชื่อผู้ใช้·ฟิลด์กำหนดเอง, การกรอง และการ query ด้วย SQL
  • บอตสามารถทำได้หากอ่านและเขียนช่องทางได้พร้อมกัน
    • ตัวอย่างคือค้นหารูปแบบความยาวอย่าง 33000 ft ในช่องทาง
    • แปลงเป็นหน่วยเมตรด้วยคำสั่ง units
    • แล้วเขียนคำตอบกลับลงช่องทางเดียวกัน เช่น [metric_bot] 33000 ft is 10058.4 meters.

ตัวเปรียบเทียบและข้อสรุป

  • แม้จะยก Slack, Mattermost และ Discord มาเป็นตัวเปรียบเทียบ แต่ผู้เขียนมองว่าคู่เปรียบเทียบที่ยุติธรรมกว่าควรรวม IRC, talk, write ด้วย
  • IRC ถูกประเมินว่ามีความสามารถน้อยกว่า suc เพราะหากต้องการอ่านประวัติแชตเก่าจะต้องมี bouncer
  • ส่วน talk, ytalk, wall ผู้เขียนบอกว่ายังทำให้ใช้งานได้บน Linux distribution สมัยใหม่ไม่สำเร็จ
  • suc มอบหมายการยืนยันตัวตนให้ SSH, การควบคุมการเข้าถึงและความสามารถในการประกอบต่อให้ UNIX และเก็บช่องทางไว้ในรูปไฟล์ข้อความ
  • ตราบใดที่เครื่องมือสามารถอ่านและเขียนข้อความได้ ก็สามารถเขียนมันขึ้นมาได้ด้วยภาษาใดก็ได้

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

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

 
GN⁺ 2023-07-06
ความคิดเห็นจาก Hacker News

  • นึกถึง “Master Foo and the Ten Thousand Lines” ทันที: http://catb.org/~esr/writings/unix-koans/ten-thousand.html
    เป็นเรื่องที่ Master Foo พูดกับโปรแกรมเมอร์ที่มาเยือนว่า “สคริปต์เชลล์หนึ่งบรรทัดมี แก่นแท้ของ Unix มากกว่าโค้ด C หนึ่งหมื่นบรรทัด”

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

    • ถูกต้อง เช่น คุณค่าเพิ่มหลักของ Slack ไม่ใช่ “การส่งข้อความระหว่างผู้ใช้ที่ยืนยันตัวตนแล้ว”
      ก่อนที่ Slack จะออกมาแล้วเบียดสิ่งอื่น ๆ ออกไป ก็มีแอปทั้งเชิงพาณิชย์และโอเพนซอร์สหลายสิบตัวที่ทำสิ่งนั้นอยู่แล้ว
      คุณค่าหลักของ Slack อยู่ในขั้นถัดไป คือให้ UI/UX ที่ดูดีและเข้าใจง่ายมาก จนแทบทุกคนสามารถนั่งลงแล้วใช้ได้ทันทีโดยไม่ต้องศึกษา ตั้งค่า อ่านคู่มือ หรืออบรม ไม่ต้องมีความรู้ด้านเทคนิค และแม้จะไม่เข้าใจอะไรเกินกว่า “กรอกชื่อผู้ใช้และรหัสผ่าน” ส่วนที่เหลือก็ดูชัดเจนในตัวเอง
    • เป็นมุมมองที่เฉียบมาก ถ้าอย่างนั้นคุณค่าของ Slack ก็คือ ความเป็นมิตรต่อผู้ใช้ และ suc ก็ไม่ใช่สำหรับผู้ใช้ทั่วไปแน่นอน
      แต่ก็เกิดคำถามที่ยากกว่า: เมื่อเทียบกับทางเลือกอย่างการฝึกผู้ใช้ให้เรียกคำสั่งพื้นฐานบน command line ได้ ราคา Slack คุ้มค่าขนาดนั้นหรือไม่? แล้วถ้าพิจารณาด้วยว่า Slack จับข้อมูลไว้และไม่คืนกลับมาให้ล่ะ? ค่าใช้จ่ายในการย้ายออกจาก Slack แพงแค่ไหน?
      suc ใช้งานไม่สะดวกก็จริง แต่ดูเหมือนว่าอาจพัฒนาไปสู่บางอย่างที่เทอะทะน้อยกว่าและผูกขาดน้อยกว่า Slack ได้

  • ชอบผลลัพธ์โดยตัวมันเอง การได้เห็นว่า ความสามารถในการประกอบกัน สามารถสร้างอะไรได้บ้างนั้นเจ๋งดี
    แต่การเอาไปเทียบกับ Slack อะไรทำนองนั้นไม่ค่อยโดนใจนัก คงไม่มีวิศวกรคนไหนอยากรับผิดชอบของที่ปะติดปะต่อแบบนี้ใน production แล้วจะจ้างคนอย่างไร ทดสอบและดีบักอย่างไร ทำล็อกและ analytics อย่างไร?
    บทความนี้ลอกเลียนบางส่วนของฟีเจอร์แชตในแอปประเภท Slack แต่ฟีเจอร์แชตไม่ใช่ 100% ของแอปเหล่านี้ มันถูกสร้างขึ้นในบริบทที่ต่างกันโดยสิ้นเชิง ดังนั้นการโจมตีสภาพเดิมว่าเทอะทะจึงดูเหมือนการตีความแบบบิดเบี้ยวสไตล์ Stockton Rush ซอฟต์แวร์มีความเทอะทะอยู่จริง แต่ “แม่ดูสิ ผมทำเรือดำน้ำจากเศษของจิปาถะได้ เพราะงั้นเรือดำน้ำแพง ๆ ก็โง่น่ะสิ” ไม่น่าจะเป็นข้อโต้แย้งที่ผู้เขียนตั้งใจสื่อ

    • ประเด็นคือ เมื่อพื้นที่ผิวของ codebase เล็กลง สิ่งเหล่านั้นจำนวนมากก็สำคัญน้อยลง
      ยูทิลิตีแต่ละตัวมักทำความเข้าใจ ทดสอบ และดีบักแยกเป็นหน่วย ๆ ได้ง่าย และ logging ก็มีอยู่ในระบบแล้ว ไม่ใช่ว่ามี syslog อยู่หรือ? แล้ว analytics จำเป็นไปทำไม?
    • ตอนอ่าน ผมก็มองแบบนั้นเหมือนกัน เป็นงานวิศวกรรมที่ยอดเยี่ยมและอ่านสนุก แต่ถ้าเทียบกับ IRC เฉย ๆ แทนที่จะเป็น Slack น่าจะตรงไปตรงมากว่า
      ถึงอย่างนั้นก็อยากรู้จริง ๆ ว่าเครื่องมืออย่าง Slack จะหน้าตาเป็นอย่างไร หากให้ความสำคัญกับความเรียบง่ายอย่างจริงจังเหนือฟีเจอร์ใหม่ ๆ ดูเหมือนว่าทุนนิยมโดยรวมไม่ได้ส่งเสริมการพัฒนาแบบนี้ จึงไม่ค่อยมีตัวอย่างซอฟต์แวร์องค์กรที่เรียบง่ายเท่าที่เป็นไปได้อย่างสมเหตุสมผลอยู่มากนัก แต่ก็เป็นการทดลองทางความคิดที่น่าสนใจ

  • มี ii ที่ทำงานโดยตรงบน IRC คล้าย ๆ กันด้วย: https://tools.suckless.org/ii/
    ใช้ไฟล์มาตรฐานไฟล์เดียวสำหรับทุกบทสนทนา การยืนยันตัวตนและการควบคุมการเข้าถึงให้เครือข่าย IRC จัดการเอง และมี UI อยู่แล้วมากมาย เช่นเดียวกับบทความนี้ ปลั๊กอินจะเป็นอะไรก็ได้ที่อ่านไฟล์หนึ่งแล้วเขียนไปยังอีกไฟล์หนึ่ง

  • เหมือนกับไดอะแกรม craigslist ถ้าทำไดอะแกรม spawn of unix ที่รวบรวมสตาร์ทอัพซึ่งตัดเอาช่องว่างของฟังก์ชัน Unix ไปใช้ น่าจะสนุกดี
    https://thegongshow.tumblr.com/post/345941486/the-spawn-of-craigslist-like-most-vcs-that-focus
    ftp/rsync => Dropbox
    suc => Slack
    ...

  • หากกำลังจะเลื่อนผ่านเพราะชื่อเรื่องดูเหมือนพาดหัวดักคลิก ก็ยอมรับว่ามีกลิ่นอายแบบนั้นอยู่บ้าง แต่จริง ๆ แล้วเป็นบทความที่ค่อนข้างดี
    พูดถึงยูทิลิตีชื่อ “suc”(Simple Unix Chat) ซึ่งใช้โค้ดเบสขนาดเล็กมากเพื่อทำฟังก์ชันฝั่งเซิร์ฟเวอร์แบบ Slack หรือ Discord
    จุดใหม่คือมันไม่ได้ประดิษฐ์เครื่องมือและวิธีคิดแบบ Unix ขึ้นมาใหม่ แต่ใช้ของเดิมให้เป็นประโยชน์ การยืนยันตัวตนให้ SSH จัดการ ช่องก็เป็นแค่ไฟล์ ส่วนการควบคุมแอดมิน/ม็อดเดอเรเตอร์ก็จัดการด้วยกลุ่มผู้ใช้และสิทธิ์ไฟล์ ส่วนพวก rich text หรือการอัปโหลดไฟล์ ก็แค่เขียนข้อมูลที่ต้องการลงในช่อง แล้วปล่อยให้ไคลเอนต์ตีความ บอทก็ง่ายมาก แค่ต่อ pipe เข้ากับไฟล์ช่อง
    แค่ 5 บรรทัดในบทความที่ใช้เขียนข้อความลงในช่อง คงทำ Slack clone ที่สมบูรณ์แบบไม่ได้ แต่ก็น่าประทับใจมากว่าเครื่องมือ Unix ที่เรียบง่ายจริง ๆ พาไปได้ไกลแค่ไหน

    • แพลตฟอร์มแชตที่มีอยู่ไม่ได้ “ประดิษฐ์” เครื่องมือ Unix ขึ้นมาใหม่ แต่ไม่ได้ใช้เพราะมันไม่เหมาะจะสร้างต่อยอดบนสิ่งนั้น
      มีเหตุผลที่แทบไม่มีระบบโปรดักชันขนาดใหญ่ที่เขียนด้วยเชลล์สคริปต์และยึดพาราไดม์ “ทุกอย่างคือไฟล์” อยู่เลย ในโลกจริง มันเป็นแนวทางที่ยอมรับไม่ได้สำหรับระบบที่ไม่ใช่ของเล่นและต้องใช้งานได้จริง
    • สำหรับผู้ใช้ปลายทางส่วนใหญ่ Slack คือ ไคลเอนต์
      ในนั้นมี UI สำหรับแอดมิน, UI จัดการผู้ใช้, ความสามารถในการขยายระบบ, webhook และอื่น ๆ การบอกว่า “ถ้าทุกคนล็อกอินเข้าเครื่องนั้น ก็แชตกับผู้ใช้คนอื่นบน Linux ได้” ไม่ได้จัดการอะไรในรายการเหล่านี้เลย ฟีเจอร์แบบนั้นมีอยู่ใน *nix ทุกตัวมาตั้งแต่ก่อนผู้อ่านส่วนใหญ่ที่นี่เกิดเสียอีก
    • กรณีนี้ดูเหมือนว่า ไฟล์แบบ append-only จะเหมาะมาก เพราะสามารถรับประกันได้ว่าผู้ใช้ทั่วไปและบอทจะแก้โพสต์ของคนอื่นไม่ได้
      น่าเสียดายที่ฟีเจอร์ของ Plan 9 นี้ยังไม่ได้ถูกพอร์ตมายัง Linux มันเป็นบิตสิทธิ์ที่คล้ายกับ “อ่าน” หรือ “เขียน” แต่เจาะจงกว่ามาก
    • คำว่า “ใช้เครื่องมือและวิธีคิดแบบ Unix ที่มีอยู่” แทบจะกลายเป็นคำอธิบายว่า “ทำ X ได้ด้วยจำนวนบรรทัดโค้ดที่น้อยจนน่าเหลือเชื่อ” เสมอ
      ไม่ได้โทษผู้เขียนนะ และในบทความเองก็พูดเรื่องนี้ไว้อย่างตรงไปตรงมามาก

  • Slack กับ Discord มี การแชร์หน้าจอ และ แชตเสียง สิ่งนี้ไม่ใช่ฟีเจอร์เสริม แต่เป็นฟีเจอร์ที่ค่อนข้างชี้ขาดต่ออำนาจครองตลาด

    • ชี้ขาดก็จริง แต่รู้สึกว่าคุณภาพกำลังแย่ลงเรื่อย ๆ

  • ต้องยอมรับตั้งแต่แรกอย่างตรงไปตรงมาด้วยว่าบล็อกโพสต์นี้เกี่ยวกับ suc และชื่อเรื่องอาจทำให้เข้าใจผิดได้นิดหน่อย แต่สุดท้ายแล้วก็มีสารสำคัญที่ไม่ได้เกี่ยวข้องโดยตรงกับ suc
    ซอฟต์แวร์สมัยใหม่แทบทั้งหมดบวมอย่างรุนแรง ความคิดที่ว่าเซิร์ฟเวอร์แชตที่มีฟีเจอร์ครบต้องใช้โค้ด 1.7 ล้านบรรทัด นั้นไร้สาระมาก ถ้าพูดแบบ Bill Gates ผมคง “ใช้” โค้ดจำนวนเท่านั้นกับเซิร์ฟเวอร์แชตไม่ได้ ต่อให้พยายามแล้วก็ตาม
    ขอปรบมือให้ ไม่ใช่แค่เพราะช่วยชี้ปัญหาหรือเสนอทางเลือก แต่เพราะเตือนว่าเราไม่จำเป็นต้องประดิษฐ์ล้อขึ้นมาใหม่ การนำคุณสมบัติของระบบและซับซิสเต็มที่มีอยู่ เช่น ใช้ SSH สำหรับการยืนยันตัวตนและการเข้ารหัส ไปใช้อย่างชาญฉลาด แม้จะต่างจากวัตถุประสงค์ที่จินตนาการไว้เดิม แต่ยังสอดคล้องกับเจตนาของคุณสมบัตินั้น เป็นตัวอย่างที่ดีของ จิตวิญญาณแฮกเกอร์
    หวังว่าโลกซอฟต์แวร์จะเรียนรู้จากแนวคิดนี้ได้มาก ต้นทุนที่ต่ำลง ระยะเวลาพัฒนาที่สั้นลง และเวลาวิศวกรรมที่สูญเปล่าน้อยลงกับการเขียนโค้ดที่ทำหน้าที่เหมือนกันซ้ำ ๆ ล้วนดีต่อทั้งนักพัฒนา บริษัท ผู้ใช้ปลายทาง และท้ายที่สุดก็ดีต่อมนุษยชาติ ผมอยากเห็นการทำลายล้างเชิงสร้างสรรค์แบบนี้มากขึ้นในอนาคต และอยากลองนำเทคนิคฉลาด ๆ แบบนี้ไปใช้ในโปรเจกต์ของตัวเองด้วย

    • สำหรับข้อมูลเพิ่มเติม บรรทัดโค้ด TypeScript ส่วนใหญ่อยู่ใน การทดสอบ E2E[0] และไดเรกทอรี webapp[1] ตามที่ชื่อบอกไว้ webapp มี “โค้ดไคลเอนต์ของเว็บแอป Mattermost” อยู่
      ดังนั้นจริง ๆ แล้วควรนับเฉพาะบรรทัดโค้ด Go จึงจะถูกต้องกว่า
      [0] https://github.com/mattermost/mattermost/tree/master/e2e-tests
      [1] https://github.com/mattermost/mattermost/tree/master/webapp
    • ผมเคยอยู่ในการประชุมเพื่อเลือกเว็บเฟรมเวิร์กสำหรับการยืนยันตัวตนที่จะใช้กับไซต์หนึ่ง แต่การถกเรื่องเล็ก ๆ น้อย ๆ แบบ bikeshedding ทำให้ยืดเยื้อมาก จนระหว่างประชุมผมลงมือทำเองบนพื้นฐานฟีเจอร์ authentication ที่ HTTP มีให้อยู่แล้ว และทำเดโมได้ก่อนประชุมจบ
    • โดยหลักการแล้วเห็นด้วย แต่ความบวมส่วนใหญ่เกิดจากการพยายามรองรับหลายแพลตฟอร์มด้วยโค้ดเบสเดียว
      โดยทั่วไปนี่เป็นไอเดียที่ดี เพราะช่วยเร่งความเร็วในการออกผลิตภัณฑ์และลดขนาดองค์กรได้ แต่ก็มี trade-off ใหญ่ด้านความซับซ้อนและ abstraction ยิ่งระดับ abstraction สูงขึ้นก็อาจยิ่งแย่ลง ดังนั้นมันไม่ได้ไม่มีเหตุผลเลย

  • ปัจจุบันดิสโทรส่วนใหญ่ป้องกันไม่ให้สร้าง setuid bash script ด้วยเหตุผลด้านความปลอดภัย
    แต่สามารถได้ผลแทบเหมือนกันด้วยรายการ sudoers เฉพาะบางรายการ

    • จริง ๆ แล้วไม่ใช่แค่ bash แต่แทบทุก shebang script ก็เป็นแบบนั้น ข้อยกเว้นน่าจะมีแค่สคริปต์ Perl เท่านั้น เพราะเมื่อ uid != euid โหมด taint จะถูกเปิดโดยอัตโนมัติ
      https://perldoc.perl.org/perlsec#Taint-mode
      ในบางระบบอาจมี race condition ในระดับพื้นฐานอยู่:
      https://perldoc.perl.org/perlsec#Shebang-Race-Condition
      การใช้ sudo -T ก็น่าดูไว้เช่นกัน:
      https://perldoc.perl.org/perlsec#Using-Sudo
      น่าเสียดายที่ Ruby เพิ่งเอาโหมด taint ออกไป การติดตาม taint เป็นกลไกทรงพลังที่ไปได้ไกลกว่าสคริปต์มาก ตัวอย่างเช่น ถ้า #html_safe ของ Rack/Rails ถูกจัดการด้วยการติดตาม taint มันก็จะทำงานได้รัดกุมกว่าเดิม และอาจป้องกัน SQL injection บางประเภทได้ตั้งแต่ระดับการออกแบบ โดยให้ระเบิดทันทีที่มีการนำสตริงผู้ใช้ที่ติด taint ไปต่อ/แทรก/ฟอร์แมตกับชิ้นส่วน SQL
      สมัยก่อนก็มีคนที่ใช้การติดตาม taint ใน CGI/mod_perl ได้อย่างมีประสิทธิภาพมาก มันไม่ใช่ยาครอบจักรวาลแน่นอน แต่ก็ยังเป็นเครื่องมือที่ค่อนข้างได้ผล
    • ใช้ C wrapper ที่เรียกเชลล์สคริปต์ หน้าตาอาจไม่สวย และต้องทำให้สคริปต์แข็งแรงขึ้นอีกหน่อย แต่ใช้งานได้ :)
      https://gitlab.com/edouardklein/suc/-/blob/master/suc_wrapper.c
    • มีดิสโทรที่อนุญาตแบบนั้นจริง ๆ เหรอ? ตอนที่ผมลองทำเอง เอกสารที่อ่านมาทั้งหมดบอกว่า setuid จะไม่ถูกนำไปใช้ เพราะสิ่งที่รันจริง ๆ ไม่ใช่ไฟล์นั้นเอง แต่เป็นเป้าหมายที่ระบุไว้ใน shebang
      ระหว่างอ่าน ผมก็หวังว่าจะมีวิธีสักอย่าง จนกระทั่งได้เห็นไฟล์ wrapper ใน GitLab repository

  • นี่เป็นอีกเรื่องหนึ่ง แต่แปลกใจที่ไม่ได้พูดถึง talk(1): https://man.netbsd.org/talk.1

    • หรือจะมี write(2) ด้วย[1] ผมนึกถึง ntalk ขึ้นมาทันที เพราะครั้งสุดท้ายที่ใช้ของแบบนั้นบนเครื่องเดียวกันก็คือตอนนั้น ตอนนั้น IRC ยังไม่ได้เข้ารหัส
      ข้อดีคือสามารถกำหนดให้รับเฉพาะในเครื่อง local ได้ และถ้าเป็นอย่างนั้นก็ต้องมีบัญชีผู้ใช้บนเครื่องนั้น จึงเหมาะกับที่อย่าง SDF หรือคลัสเตอร์ขนาดใหญ่กว่า ส่วนการยืนยันตัวตนก็ไม่ต้องทำเอง ให้ PAM หรือ BSD_Auth จัดการไป ซ็อกเก็ตหรือการเข้ารหัสก็ไม่ต้องทำเอง ให้ TLS จัดการไป จะใช้วิธี SSH เข้า secure shell แล้วใช้ tmux กับ (n)talk ก็ได้
      แน่นอนว่า (n)talk เขียนด้วย C ดังนั้นจึงไม่ใช่ bash 5 บรรทัด
      [1] https://man7.org/linux/man-pages/man2/write.2.html