DebConf11 Day 3: Rolling, Multiarch, TDD

DebConf11 วันที่ 3 ที่ผมเข้าฟังก็มีเรื่อง พบ Release Team, พบ Debian Sysadmins (DSA), Rolling BoF, Packaging with Git, Multiarch, Test-Driven Development

เรื่องที่เป็นประเด็นน่าสนใจของวันนี้คงอยู่ที่ rolling release, multiarch support และ test-driven development ซึ่งเป็นเรื่องใหม่ที่มีการเสนอเข้า Debian ในรุ่น Wheezy นี้

สำหรับ CUT และ rolling release นี้ release team บอกว่าไม่มีปัญหา แต่อย่าให้ release team ต้องทำงานหนักขึ้นเป็นพอ ใน BoF นั้น Raphael Hertzog ได้เริ่มจากการพูดถึงจุดมุ่งหมายของ rolling release ว่าเป็นการเจาะกลุ่มผู้ใช้เดสก์ท็อปทั่วไป ไม่ใช่สำหรับผู้ใช้เซิร์ฟเวอร์ ซึ่งหมายความว่า สถาปัตยกรรมที่จะมีการใช้งานจริง ๆ อาจจะเหลือแค่ i386, amd64, armel ก็ได้

คำถามถัดมาคือ สามารถใช้ testing เป็น rolling ได้เลยไหม?

• testing นั้นมีการอัปเดตสม่ำเสมอแน่ละ แต่มัน usable อย่างสม่ำเสมอด้วยหรือเปล่า?
• เราพร้อมจะรองรับผู้ใช้ testing เต็มที่จริง ๆ หรือเปล่า? นี่ต้องเป็นภาระของ maintainer ทั้งหลายที่เพิ่มขึ้น
• เราพร้อมจะแก้บั๊กให้แบบทันเหตุการณ์ได้หรือเปล่า? (โดยปกติ การอัปโหลดแพกเกจจะเอาขึ้นที่ unstable รอจนกระทั่ง ๑๐ วันผ่านไปโดยไม่มีบั๊กร้ายแรงจึงจะผ่านเข้า testing ยกเว้น security bug จึงจะมีการอัปโหลดเข้า testing แบบทันทีทันใด และถ้าเป็นกรณี migration เป็นชุดจะใช้เวลานานขึ้นอีก เพราะต้องรอ migrate พร้อมกัน)
• มี installer ที่ดีหรือเปล่า? (โครงการ CUT จะทำ installer ที่ใช้การได้อย่างสม่ำเสมอสำหรับ testing)

จากการสอบถามคำถาม ๓ ข้อ คือ

1. testing usable ไหม?
2. Debian ควรรับรองให้ผู้ใช้ใช้ testing อย่างเป็นทางการไหม?
3. เราพร้อมจะ support ผู้ใช้ testing อย่างเต็มที่ไหม?

คำตอบของ DD ส่วนใหญ่จะตอบ yes ในข้อแรก แล้ว yes น้อยลงเรื่อย ๆ ในข้อหลัง ๆ

ผมคิดว่าความเห็นส่วนใหญ่จะเป็นว่า stable นั้นเก่าเกินไปสำหรับผู้ใช้เดสก์ท็อป ส่วน unstable ก็ต้องอาศัยประสบการณ์พอสมควรในการดูแลระบบ จะมี testing ที่อยู่กลาง ๆ และแนะนำให้ผู้ใช้เดสก์ท็อปมือใหม่ใช้ แต่ถ้าจะถึงกับประกาศให้ใช้เป็นทางการนั้น จะต้องมีการปรับเปลี่ยนระบบการทำงานพอสมควร ซึ่งเมื่อเปรียบเทียบข้อดีข้อเสียแล้ว DD หลายคนจึงเลือกตอบ no มากกว่า แม้การใช้ testing ปัจจุบันก็ไม่ได้ส่งผลเสียอะไรขนาดนั้น (DD บางคนถึงกับบอกว่า unstable + apt-listbugs นั่นแหละดีที่สุดแล้ว)

ในอีกทางหนึ่ง ก็มี DD บางคนได้ทำงานล่วงหน้าไปแล้วเพื่อทดลองกระบวนการต่าง ๆ ที่จะใช้กับ rolling

คำถามถัดมาคือ แล้วจะทำอย่างไรให้ rolling นั้น rolling ต่อไปเรื่อย ๆ โดยเฉพาะในช่วง freeze? ก็มีแนวทางอย่างน้อย ๒ แนวทาง:

• ทำ symlink ให้ rolling == testing ในช่วงปกติ แล้ว fork rolling ในช่วง freeze
  • DD ต้องแยกสมาธิดูแลทั้ง testing และ rolling แยกกันในช่วง freeze อาจทำให้ออก stable ช้าลงไปอีก
• ทำ rolling แยกต่างหากเลย
  • สามารถสร้างกฎใหม่ ๆ ได้
  • อาจเป็นอุปสรรคต่อการออก stable มากขึ้นไปอีก?

ครั้งนี้เป็นการระดมสมอง ยังไม่มีการตัดสินใจอย่างใด

ข้ามมาที่เรื่อง Multiarch ซึ่งหัวเรี่ยวหัวแรงคือ Steve Langasek เล่าว่า เริ่มมีแนวคิดนี้มาตั้งแต่ปี 2009 ที่ Barcelona จนกระทั่งเริ่ม implement ครั้งแรกใน Ubuntu 11.04 เพียงไม่กี่แพกเกจ เพียงเพื่อให้สามารถติดตั้ง flash plugin แบบ i386 บน amd64 ได้เท่านั้น แล้วจึงมาเริ่มทำใน Debian ในรุ่น Wheezy นี้ โดยทยอยแก้ไขไลบรารีต่าง ๆ ให้รองรับ multiarch ทั้งระบบ ซึ่งเป็นการย้ายขนานใหญ่กว่าใน Ubuntu มาก

สิ่งที่ Steve ได้เรียนรู้จากการผลักดันครั้งนี้คือ:

• เอกสารประกอบนั้นสำคัญมาก ไม่ใช่แค่แก้ policy แล้วก็จบ แต่ต้องมีเอกสารสรุปให้ทุกคนทำตามได้โดยสะดวกด้วย
• แบ่งงานเป็นส่วน ๆ ทำไปทีละส่วน เพราะไลบรารีต่าง ๆ มีความสัมพันธ์กันเป็นชุด ๆ
• ไม่มีอะไรที่จะคงอยู่ถาวรไปกว่าวิธีแก้แบบชั่วคราวอีกแล้ว (Nothing is so permanent as temporary solution.) ดังนั้น อย่าคิดแต่ว่าจะแก้แบบชั่วคราวไปก่อน

สิ่งที่เราจะได้จากการรองรับ multiarch คือ:

• สภาพแวดล้อมสำหรับการจำลองเครื่องต่าง ๆ แบบทันทีทันใด ไม่ต้องไปอาศัย chroot อีกแล้ว
• การคอมไพล์ข้ามสถาปัตยกรรม (cross-compilation) ไม่ใช่เรื่องยากอีกต่อไป (Steve สาธิตการคอมไพล์แพกเกจสำหรับ arm โดยไม่ต้องใช้ chroot ไม่ต้องติดตั้งอะไรพิเศษ เสร็จในเวลาอันรวดเร็ว)
• การปรับระบบข้ามสถาปัตยกรรม (cross-grading) ทำได้ทันทีโดยไม่ต้องเริ่มติดตั้งใหม่ เช่น จาก arm เป็น armel, จาก i386 เป็น amd64, จาก armel เป็น armhf
• รองรับซอฟต์แวร์ที่แจกจ่ายแบบไบนารีอย่างเดียว (เช่น Adobe flash player) ได้ดีขึ้น

ส่วนเรื่องสุดท้าย คือ test-driven developement นั้น เริ่มจากสรุประบบการทดสอบคุณภาพที่ Debian มีอยู่แล้ว เช่น archive rebuild (จับบั๊ก FTBFS), lintian, piuparts, auto-REJECT ที่ ftp-master, การทดสอบแพกเกจขณะคอมไพล์ (make check), การทดสอบการเชื่อมรวม (EDOS), การวิเคราะห์ซอร์สโค้ดแบบอัตโนมัติ (CADA)

จากนั้นก็เป็นการสอบถามทุกคน ว่ายังมีการทดสอบแบบใดอีกไหมที่ตนเองทำอยู่ เผื่อจะนำมาใช้ใน Debian โดยรวมต่อไป

รายละเอียดขอจบเพียงเท่านี้ เนื่องจากเวลาในการเขียน blog หมดลงแล้ว..

DebConf11 Day 2: DPL, QA

DebConf11 วันที่สอง เป็นการเริ่มเข้าสู่โหมด conference อย่างแท้จริง เนื้อหาจะเริ่มเจาะกลุ่ม contributor ทั้งหลาย

เริ่มจาก เจ้าภาพมาเล่าถึงที่มาที่ไปของการจัด DebConf ที่บอสเนียในครั้งนี้ แม่งานของทางเจ้าภาพ คือ Adnan Hodzic ประธานกลุ่ม NVO DIVA เริ่มมีแนวคิดจะจัด DebConf ที่บอสเนียมาตั้งแต่ DebConf 7 และการเสนอตัวนั้น ทางเจ้าภาพก็ยังไม่คาดคิดว่าจะได้จัด แต่ก็พยายามผลักดันเต็มที่ โดยเข้าหารัฐบาล จนหน่วยงานของรัฐเห็นชอบ หลังจากนั้นรัฐบาลก็เป็นฝ่ายสนับสนุนออกเงินทุนให้ทุกอย่าง ดังจะเห็นได้จากพิธีเปิดในวันแรก มีคนระดับสูงของรัฐบาลมากล่าวเปิดงานหลายคน ตั้งแต่ระดับรัฐมนตรีลงมา

ทีมเจ้าภาพทำงานร่วมกับทีมจัดงานของเดเบียนอย่างใกล้ชิด เข้าไปคุยกับรัฐบาลด้วยกัน ทรงผมของ Holger ไม่เป็นอุปสรรคต่อการเข้าพบรัฐมนตรี หลังจากที่ Adnan convince รัฐบาลได้แล้ว

ผมเองยอมรับว่าทีมเจ้าภาพทำงานแข็งขันมาก เอาแค่เรื่องวีซ่าของผู้เข้าร่วมงานก็ต้องเตรียมการอย่างดี ตามแก้ปัญหาต่าง ๆ อย่างกรณีของผมเป็นต้น ซึ่งเขาทำงานได้ไม่ขาดตกบกพร่อง

ถัดมาเป็น session แรกของ DPL (Stefano Zacchiroli) พูดถึงจุดแข็งจุดอ่อนของ Debian และแนวทางของโครงการที่จะทำต่อไป

ในช่วงแรก ๆ หลังการก่อตั้ง Debian นั้น มี distro ไม่หลากหลาย Debian จึงมีจุดเด่นชัดเจน แต่ทุกวันนี้มี distro มากมายมหาศาล แล้วอะไรที่ยังเป็นความพิเศษของ Debian อยู่?

• คุณภาพ (quality) Debian มีวัฒนธรรมของความเป็นเลิศทางเทคนิค มีตั้งแต่ policy ที่แน่นหนา มีเครื่องมือควบคุมคุณภาพอย่าง lintian, piuparts, การ rebuild แพกเกจทั้ง archive เพื่อตรวจสอบบั๊กประเภท FTBFS (Fails-To-Build-From-Source) เป็นระยะ โดยทุกแพกเกจได้รับการตรวจสอบเท่าเทียมกันหมด ผู้ดูแลแพกเกจล้วนแต่เป็นผู้เชี่ยวชาญด้านซอฟต์แวร์ และที่สำคัญคือนโยบาย we release when it's ready
• เสรีภาพ (freedom) Debian ได้ส่งเสริมวัฒนธรรมซอฟต์แวร์เสรีอย่างแข็งขันมาตั้งแต่ปี 1993 ทุกอย่างใน Debian เป็นซอฟต์แวร์เสรีทั้งหมด ตั้งแต่ตัวซอฟต์แวร์เอง, โครงสร้างพื้นฐานที่ใช้ดำเนินโครงการ, และความเปิดกว้างในกระบวนการทำงาน สิ่งที่บุคคลภายนอกรับรู้คือ Debian ไม่ทรยศต่ออุดมการณ์ซอฟต์แวร์เสรีเด็ดขาด และยังมีมาตรฐานสูงในเรื่องการส่งเสริมเสรีภาพด้วย
• ความเป็นอิสระ (independence) Debian อยู่ได้ด้วยการทำงานของอาสาสมัครล้วน ๆ ไม่มีโครงสร้างแบบบริษัทหรือลำดับชั้นการบริหารงาน ไม่มีบริษัทใดบริษัทหนึ่งคอยค้ำจุนหรือชี้นำได้ แต่อยู่ได้ด้วยการบริจาค (ทั้งในรูปตัวเงินและฮาร์ดแวร์) และวัฒนธรรมการให้
• กระบวนการตัดสินใจ (decision making) มีสองส่วน คือ do-ocracy และ democracy โดย do-ocracy คือการให้อำนาจตัดสินใจกับคนที่ลงมือทำ ส่วน democracy คือการใช้เสียงส่วนใหญ่ของชุมชนตัดสินปัญหา do-ocracy มักใช้กับงานทางเทคนิค และ democracy มักใช้กับสิ่งที่นอกเหนือจากนั้น ซึ่งผลของ do-ocracy คือ เครดิตจะติดตัวคนทำไปด้วย
• งานปลายน้ำ (derivatives) Debian เป็นต้นน้ำให้กับ distro ปลายน้ำที่ยัง active อยู่ประมาณ 130 distro ซึ่ง distro เหล่านี้ยังคงใช้ประโยชน์จาก Debian และพึ่งพา Debian อยู่ (แม้ผู้ใช้จำนวนมากจะไม่ทราบก็ตาม) ถ้า Debian ทำงานผิดพลาด จะมีคนเดือดร้อนจำนวนมาก

เหล่านี้คือจุดแข็งของ Debian แต่จุดแข็งเหล่านี้ก็สามารถย้อนกลับมาเป็นอุปสรรคได้เช่นกัน

• ขาดคน? ปีที่แล้ว คน Debian บ่นกันมากว่า Debian ขาดคนทำงาน แต่ถ้าดูสถิติปีนี้ก็จะเห็นว่าสามารถดึงดูดคนเข้าร่วมได้มากพอสมควร (DD เพิ่มขึ้น 25 คน, DM เพิ่มขึ้น 30 คน ปัจจุบันมี DD 911 คน และ DM อีก 149 คน)
• คุณภาพ? การทำงานที่มีคุณภาพนั้นใช้เวลานาน แต่จากสถิติ เราก็ทำได้ดีขึ้น (etch ใช้เวลา 22 เดือน, lenny 22 เดือน, squeeze 24 เดือน ในขณะที่ยังต่ำกว่าเวลาเฉลี่ยคือ 25 เดือน) แนวทางที่จะทำคือ ใช้นโยบาย time-based freeze, ใช้กระบวนการ release ที่ทุกคนต้องร่วมกันรับผิดชอบ (ไม่ใช่ดูแค่แพกเกจของตัวเอง), รวมทั้งการเสนอ trade-off อย่าง CUT หรือ rolling
• เสรีภาพ? การตั้งมาตรฐานสูงเรื่องเสรีภาพจะเป็นอุปสรรคไหม? คำตอบสั้น ๆ คือ ไม่ โดยมีวงเล็บต่อท้ายว่า (Well, maybe, but it's not negotiable) (ได้รับเสียงปรบมือเกรียวกราวในห้องประชุม)
• ความเป็นอิสระและ do-ocracy? ข้อเสียคือเรื่องนี้กระตุ้นได้แต่งานทางเทคนิค ไม่สามารถกระตุ้นการทำงานอย่างอื่นที่ไม่ geek ได้ เช่น งานเอกสาร งานตรวจสอบ งานบริหาร งานประชาสัมพันธ์ งานบัญชี งานด้านกฎหมาย ฯลฯ แต่งานเหล่านี้ก็ขาดเสียมิได้ มิฉะนั้นพวก geek ก็ hack กันไม่ถนัดเหมือนกัน แนวทางที่ควรทำคือ ให้การยอมรับงานเหล่านี้มากขึ้น เปิดรับผู้เข้าร่วมด้านต่าง ๆ มากขึ้น รวมทั้งทุกคนเองก็ต้องพร้อมอาสาเข้ามาทำด้วย
• democracy? แน่นอนว่าการใช้ประชาธิปไตยจะทำให้เกิดความล่าช้าโดยธรรมชาติ เพราะจะต้องมีคนบางส่วนที่ไม่เห็นด้วยและอภิปรายคัดค้าน แต่ก็ต้องเข้าใจว่า ประชามติ (concensus) กับ เอกฉันท์ (unanimity) เป็นคนละเรื่องกัน และแม้เราจะใช้ทั้ง democracy และ do-ocracy แต่ถ้าจะต้องการให้อะไรเกิดขึ้นก็ต้องลงมือทำ! แนวทางที่ควรทำคือ สนับสนุนเทคโนโลยีที่ทำให้เกิดการ fork ได้ เช่น PPA, test-driven development ซึ่งได้มีการเสนอใน Debian กันอยู่
• งานปลายน้ำ? distro ปลายน้ำบางครั้งก็เป็นอุปสรรคได้ ถ้าเขาลดทอนอุดมคติของเราลง แต่ในขณะเดียวกัน งานปลายน้ำก็อาจเป็นผลดีได้ เพราะเขาช่วยเจาะกลุ่มผู้ใช้กลุ่มต่าง ๆ ให้ โดยสิ่งที่จะเป็นผลดีกับทุกคน คือการสมทบงานกลับไปสู่ต้นน้ำ แนวทางที่ควรทำคือ ส่งเสริมการทำงานร่วมกันระหว่างงานปลายน้ำและต้นน้ำ, พยายามอธิบายแนวคิดของ Debian ให้กับผู้เข้าร่วมต่าง ๆ ได้รับทราบ, เผยแพร่วัฒนธรรมการตอบแทนกลับคืนสู่ชุมชน (give-back) ของ Debian ตาม Social Contract ข้อ 2

ข้อสรุปคือ:

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

ถัดจากนั้น อ.กิตติ์กับผมได้แยกไปฟังกันคนละห้อง อ.กิตติ์อยู่ในห้องประชุมใหญ่ ผมไปฟังห้องเล็ก

ห้องเล็กวันนี้ เนื้อหาเป็นเรื่องของการควบคุมคุณภาพ (QA) ใน Debian

เรื่องแรกคือ มีการเสนอมาตรการกลั่นกรองคุณภาพซอฟต์แวร์ที่จะเข้าสู่ Debian โดยปัจจุบัน Debian มีซอฟต์แวร์หลากหลายมาก ซอฟต์แวร์บางตัวเขียนโค้ดยุ่งเหยิง แก้บั๊กยาก ควรจะให้เข้า Debian หรือไม่? โดยมีการเสนอมาตรการการให้คะแนนคุณภาพซอฟต์แวร์ไว้ดังนี้:

• ไม่มีขีดกำหนดตายตัว คะแนนรวมจะเป็นตัวเลขบอกระดับคุณภาพเท่านั้น ไม่มีขีดขั้นว่าเท่าไรจึงจะผ่านเกณฑ์ แต่จะอาศัยความกดดันทางสังคมเป็นหลัก
• uniqueness คือถ้าซอฟต์แวร์นั้นไม่มีซอฟต์แวร์ทดแทนอื่นแล้ว ก็จำเป็นต้องให้คะแนนไว้ แม้คุณภาพโค้ดจะไม่ดีก็ตาม เพื่อให้คง feature ไว้
• ตำแหน่งใน dependency tree ถ้าซอฟต์แวร์นั้นมีแพกเกจอื่น depend อยู่มาก ก็จำเป็นต้องให้คะแนนไว้เช่นกัน
• สถิติ popcon ถ้ามีผู้ใช้เยอะ ก็ให้คะแนนสูง
• ข้อมูลใน UDD เกี่ยวกับจำนวนบั๊ก ความสม่ำเสมอในการดูแลแพกเกจ
• จำนวนรูโหว่ที่พบ โดยนับเป็นจำนวน CVE-ID ต่อ LOC
• ปริมาณ comment โดยคิดสัดส่วนต่อ LOC (ใช้ ohcount)

โดยอาจจะเริ่มจากการประเมินคุณภาพแพกเกจที่มีอยู่ทั้งหมดก่อน เพื่อให้เกิดค่ากลางที่แพกเกจใหม่ ๆ สามารถเปรียบเทียบตัวเองได้ ว่าเข้าขั้นหรือยัง

เรื่องอื่น ๆ ที่เสนอคือ อาจให้ ITP ต้องมี DD รับรอง 2 คนไหม? DD อาจทำ peer-review กันเองผ่าน mentors ด้วยดีไหม นอกเหนือจากการ mentor sponsoree?

เรื่องที่สองเป็นสถานะของ Ruby ใน Debian โดยได้พูดถึงอุปสรรคต่าง ๆ ที่ผ่านมาและการแก้ไข

อุปสรรคหลักคือ Ruby พัฒนาโดยคนญี่ปุ่น เมลลิงลิสต์ที่นักพัฒนาคุยกันจะใช้ภาษาญี่ปุ่นเป็นหลัก ทำให้เข้าร่วมได้ยาก นอกจากนี้ Ruby ยังมีระบบแพกเกจของตัวเอง คือ RVM และ Rubygems และไม่ยอมรับระบบแพกเกจของ distro ทำให้เกิดความไม่ลงรอยกันกับทีม Debian แต่ทีม Debian ก็ได้กำจัดข้อเสียต่าง ๆ ใน Debian จนกระทั่งได้รับการยอมรับแล้ว และได้สร้างเครื่องมือ gem2deb เพื่อแปลงแพกเกจ Rubygems ให้เป็น source package ของ Debian และได้ทยอยแปลงแพกเกจใน Debian ให้ใช้รูปแบบใหม่นี้ไปเรื่อย ๆ ทีละส่วน

นอกจากนี้ก็ได้พูดถึงเป้าหมายของ Wheezy ว่าอาจจะใช้ Ruby 1.9.3 มี Jruby ใน non-free ส่วน Rubidious นั้นอยู่ระหว่าง ITP ในโหมดที่เรียกว่า cookie-licking (หมายความว่า เจ้าของบั๊กบอกว่ากำลังทำ ๆ มาเป็นเวลานาน แต่ไม่มีความคืบหน้า คนอื่นจะเข้าไปทำก็ไม่กล้า เปรียบเหมือนการเลียคุกกี้แต่ไม่กิน คนอื่นจะกินก็ไม่กล้าหยิบ)

เรื่องถัดจากนั้นก็เป็นการประชุม BoF (Birds of a Feather: การประชุมระดมสมอง) ในกลุ่ม QA, Lintian และ Piuparts (อ่านว่า พิวพาร์ทส์) ซึ่งรายละเอียดขอละไว้ก่อน เนื่องจาก blog ยาวมากแล้ว และคนเขียนกำลังหิวข้าว :-P

DebConf11 Day 1: Debian Day

DebConf11 วันแรก เป็นกิจกรรม Debian Day เน้นการเผยแพร่ความรู้ทั่วไปเกี่ยวกับ Debian ให้คนทั่วไปฟัง

คนแรกที่ขึ้นพูดคือ Bdale Garbee ซึ่งนับเป็นนักพัฒนา Debian ที่ร่วมทำงานกับ Debian มายาวนานที่สุดในบรรดานักพัฒนาที่ยัง active อยู่ในปัจจุบัน (ดู บทสัมภาษณ์โดย Raphaël Hertzog) ปัจจุบันทำงานกับ HP งานอดิเรกของเขาคือสร้างจรวด!

Bdale เล่าประวัติศาสตร์ของ Debian ว่าเริ่มออกรุ่น 0.01 ในปี 1993 (เขาเข้าร่วมในปี 1994 ซึ่งเป็นปีที่ออกรุ่น 0.91) และรุ่น 0.93 ในปี 1995 ก็เริ่มใช้ dpkg จัดการแพกเกจ ถือเป็น distro แรกที่มีระบบจัดการแพกเกจแบบมี dependency

นอกจากนี้ Debian ยังเป็น distro แรกที่มีการพัฒนาแบบเปิดโดยอาศัยชุมชนล้วน ๆ โดยเป็น distro แรกที่ทำ Social Contract พร้อมกับร่าง Debian Free Software Guidelines (DFSG) เพื่อความชัดเจนในทางปฏิบัติ นอกเหนือจากหลักการ Software Freedom ของ Free Software Foundation ด้วย ซึ่งต่อมา เมื่อมีการบัญญัติคำว่า Open Source ในภายหลัง ก็ได้นำ DFSG นี้ไปใช้เป็น Open Source Definition แทบจะทั้งดุ้น มีการปรับเปลี่ยนถ้อยคำนิดหน่อยไม่ให้เจาะจง Debian เท่านั้น

Bug Tracking System (BTS) ของ Debian เริ่มใช้มาตั้งแต่ปี 1994 เป็น mail-in/web-out

มีการร่าง Debian Policy เพื่อเป็นข้อกำหนดทางเทคนิคของการทำงานร่วมกันในชุมชน

มี Debian Constitution (ธรรมนูญเดเบียน) เพื่อเป็นบทบัญญัติในการตัดสินกรณีต่าง ๆ ที่เกิดขึ้น ประกอบด้วยกระบวนการตัดสินใจอย่างเป็นแบบแผน (formal decision making), การแบ่งอำนาจหน้าที่ (Developers, Technical Committee, Project Secretary, Project Leader, Delegates), และกำหนดกระบวนการลงคะแนน (voting process)

สิ่งที่นักพัฒนาอาวุโสท่านนี้บอกว่าได้เรียนรู้มีสองเรื่อง:

• อย่าประเมินค่าของคุณค่าต่าง ๆ ต่ำเกินไป (Never underestimate value of values)
  • คุณค่า (values) ทำให้เกิดวิสัยทัศน์ (vision), กุศโลบาย (strategy) และเป้าหมาย (objectives)
  • คุณค่าเป็นเหมือนสมอยึด (anchor) เมื่อเกิดความสับสนวุ่นวายขึ้น
• สัญญาประชาคมภายใน (internal social contract) มีความสำคัญพอ ๆ กับสัญญาประชาคมภายนอก (external social contract) กล่าวคือ
  • Debian ยังขาด Code of Conduct (ระเบียบชุมชน)
  • ... (ฟังไม่ทัน) ...
  • มักเกิดเผด็จการของคนกลุ่มน้อยที่เสียงดัง (tyranny of vocal-minority) ขึ้นบ่อย ๆ

นอกจากนี้ยังได้พูดถึง facility ทางเทคนิคของ Debian เช่น ระบบแพกเกจ และระบบ auto-build ซึ่งทำให้ Debian รองรับเครื่องหลากหลายสถาปัตยกรรมได้โดยไม่เป็นภาระของนักพัฒนาเลย

คนต่อมาที่ขึ้นพูดคือ Enrico Zini ซึ่งเป็น DD ที่เต็มไปด้วยชีวิตชีวามาก ๆ คนหนึ่ง นำเสนอเรื่องในชุมชน Debian ว่ามีหลากหลายแค่ไหน เช่น:

• มีคนจากหลากหลายอาชีพ ตั้งแต่นักเรียน อาจารย์ พนักงานบริษัท เจ้าของกิจการ ไปจนถึงพนักงานดับเพลิง บางคนสร้างจรวดเป็นงานอดิเรก บางคนท่องอวกาศเป็นงานอดิเรก!
• มีคนหลายวัย ตั้งแต่เด็กไปจนแก่ บางคนมีลูกแล้ว บางคนมีหลานแล้ว บางคนลูกก็ยังมาเป็น DD อีก บางคนพบรักกันใน DebConf บางคนจัดงานแต่งงานใน DebConf บางคนมาฮันนีมูนที่ DebConf!

ดังนั้น จึงไม่ควรยึดมั่นถือมั่นอะไรมากใน Debian ยกเว้นเรื่องสำคัญที่ผูกโยงทุกคนเข้าด้วยกัน ได้แก่ Social Contract, DFSG, DMUP

เวลามีปัญหาเกิดขึ้น Debian ก็มีแนวทางแก้ปัญหาของตัวเอง โดยผ่านโครงสร้างต่าง ๆ ใน Debian Contitution (ธรรมนูญเดเบียน) ซึ่ง Bdale ได้พูดไปแล้ว

ถัดจากนั้น Jesus Climent (ผมเพิ่งทราบว่าชื่อของเขาไม่ได้ออกเสียงว่า จีซัส แต่เป็น เฮซัส) ซึ่งเป็น DD ที่ทำงานที่ Google ก็มาเล่าให้ฟังเกี่ยวกับการใช้ Debian ใน Google ซึ่งระบบต่าง ๆ ใน Debian ทำให้ Google สามารถถอดเปลี่ยน เพิ่ม หรือซ่อมแซม storage ต่าง ๆ ที่มีมากมายมหาศาลได้แบบไม่ต้องปิดระบบ ไม่ต้องรีบูต ไม่ต้องใช้คนสั่ง ทุกอย่างอัตโนมัติหมด รวมถึงการอัปเกรดและทดสอบระบบด้วย

(Jesus เข้ามาคุยกับเราก่อนหน้านั้น เขาบอกว่าเคยมาเที่ยวเมืองไทย ชอบเมืองไทยมาก ถึงขนาดไปทำรอยสักภาษาไทยไว้เป็นที่ระลึก)

ปิดท้ายด้วย Gerfried Fuchs (rhonda) พูดถึงระบบ e-card ของออสเตรีย ซึ่งเป็น smartcard สำหรับจัดการระบบแบบเชื่อมรวมทุกอย่างในบัตรเดียว โดยเริ่มจากบริการสาธารณสุขก่อนในขั้นแรก และจะขยายไปยังระบบอื่น ๆ สำหรับบริการประชาชน รวมไปถึงการขยายไปใช้ทั่วทั้ง EU ในอนาคตด้วย บริษัท SVC ของเขาพัฒนาระบบโดยใช้ Debian เป็นฐาน

Finally in Banja Luka

บันทึกการเดินทางจากขอนแก่นถึง Banja Luka เพื่อร่วมงาน DebConf11 เป็นการเดินทางที่ลุ้นระทึกตลอดทาง

ปัญหาหลักคือเรื่องวีซ่าเข้าประเทศ เริ่มจากเงื่อนไขสำคัญคือไม่มีสถานทูตบอสเนียในประเทศไทย ถ้าจะขอวีซ่าต้องไปขอที่สถานทูตบอสเนียในมาเลเซีย แต่เผอิญมาติดเงื่อนไขอีกอย่างของผม คือแม่ยังไม่หายเจ็บแขน ยังต้องคอยทำงานต่าง ๆ แทนแม่อยู่ ถ้าจะต้องเดินทางไปไหน จะต้องหาคนมาอยู่แทนให้ได้ก่อน ซึ่งก็ได้พยายามหลายทาง ตั้งแต่คุยกับน้อง ๆ (ซึ่งตอนนี้ย้ายไปอยู่ต่างจังหวัดกันหมด) ให้มาช่วยอยู่แทน ซึ่งแต่ละคนก็ติดภาระของครอบครัวตัวเองเช่นกัน หรือจะเป็นการพยายามจ้างคนที่ไว้ใจได้มาอยู่แทน แต่สุดท้ายก็ได้น้อง ๆ มาช่วยในช่วงที่ผมมาร่วม DebConf แต่ในช่วงที่ไปขอวีซ่าที่มาเลเซียนั้น ยังไม่สะดวก

เผอิญได้ข้อมูลมาว่าสามารถขอวีซ่าโดยส่งหลักฐานทาง DHL ได้ จึงฝาก อ.กิตติ์ ซึ่งจะไปด้วยกันช่วยดำเนินการให้ ซึ่งฝ่ายวิเทศฯ ของ มข. ก็ช่วยดำเนินการและติดตามผลให้เป็นอย่างดี แต่สุดท้ายจวนถึงวันเดินทาง วีซ่าก็ยังไม่ส่งกลับมา

จึงรีบติดต่อเจ้าภาพ ว่าจะสามารถขอ visa on arrival ได้หรือไม่ ซึ่งเจ้าภาพก็ดีใจหาย ดำเนินการทุกอย่างให้ โดยเข้าใจว่าเขาได้ติดต่อขอวีซ่าสำหรับผู้เข้าร่วมงานทุกคนอยู่แล้ว จึงได้ส่งหลักฐานที่จำเป็นมา ให้เรายื่นต่อสายการบินและ ต.ม. ว่าเราจะได้วีซ่าเมื่อไปถึง

ตัดฉับมาที่สนามบินสุวรรณภูมิคืนวันที่ ๒๑ ก.ค. อ.กิตติ์กับผมลงจากเครื่องบินจากขอนแก่นก็ตรงไปเช็กอินที่ Turkish Airways เพื่อเดินทางไปบอสเนีย ปรากฎว่าเจ้าหน้าที่ปฏิเสธที่จะให้เราขึ้นเครื่อง!

สาเหตุคือหลักฐานของเราอ่อนเกินไป เป็นเพียงหนังสือของเอกชนว่าได้ยื่นขอวีซ่าให้เราแล้ว แต่ยังไม่มีลายเซ็นรับรองจากรัฐบาลบอสเนียว่าเราจะได้วีซ่าแน่นอน และจากกรณีต่าง ๆ ที่เขาเคยพบในอดีตที่มีการส่งกลับจากวิธีขอวีซ่าแบบนี้ ทำให้เขาต้องปฏิเสธเราเพื่อความแน่ใจ

คืนนั้น อ.กิตติ์ จึงพาไปพักที่โรงแรมใกล้ ๆ สนามบิน และพยายามติดต่อขอหลักฐานเพิ่มเติมจากเจ้าภาพ แต่เวลานั้นที่บอสเนียเลย ๕ โมงเย็นซึ่งเป็นเวลาเลิกงานแล้ว จึงต้องรอดำเนินการในวันรุ่งขึ้น ซึ่งจะเริ่มได้ก็ตรงกับเวลาบ่ายโมงในบ้านเราเป็นอย่างเร็ว และเขายังขอหลักฐานเพิ่มเติมของเรา คือสำเนาหนังสือเดินทาง ซึ่งในยามฉุกละหุกอย่างนั้นก็มีแต่ภาพถ่ายจากกล้องมือถือเท่านั้นที่เราทำได้

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

ช่วงบ่ายวันที่ ๒๒ หลังจากเช็กเอาต์โรงแรมแล้ว ก็นั่งรออีเมลอยู่ที่ล็อบบี้ จนราวเกือบ ๕ โมงเย็นจึงมีเมลตอบกลับมาพร้อมหนังสือที่มีลายเซ็นเจ้าหน้าที่ เราจึงนำไปพิมพ์ออกกระดาษด้วยบริการของโรงแรม แล้วพยายามโทรติดต่อสายการบิน แต่โครงข่าย DTAC เจ้ากรรมดันมาเสียในช่วงเวลานั้น โทรออกไปไหนไม่ได้เลย แม้แต่โทรหากันเอง จึงตัดสินใจนั่งลีมูซีนของโรงแรมไปสนามบินเลย แล้วไปลุ้นเอาที่เคาน์เตอร์เช็กอินกันเลย

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

เป็นอันอุ่นใจว่าได้ไปแน่ แต่ยังต้องลุ้นต่อว่าจะเจออุปสรรคทำนองนี้ระหว่างทางอีกหรือเปล่า

เกือบตีสามของวันที่ ๒๓ ตามเวลาที่อิสตันบูล อ.กิตติ์กับผมก็ลงเครื่องมารอต่อเครื่องที่จะออกตอนเที่ยงไปซาราเจโว พยายามจะงีบแต่ก็ไม่หลับ นาฬิกาชีวะซึ่งเป็นเวลา ๗ โมงเช้าแล้วมันตื่นตัวเรียบร้อย เลยได้แต่นั่งอ่านหนังสือพิมพ์รอ เป็นไม่กี่ครั้งที่อ่านหนังสือพิมพ์จนครบทุกหน้า!

เกือบเที่ยง จึงไปขึ้นเครื่อง คราวนี้เจ้าหน้าที่ให้ผ่านโดยง่าย ไม่ถามหาแม้กระทั่งหนังสือรับรองที่ว่านั้น!

ราวเกือบบ่ายสองของวันที่ ๒๓ ตามเวลาที่ซาราเจโว (นาฬิกาชีวะเป็นเวลา ๑ ทุ่ม) พวกเราลงจากเครื่องมาผ่าน ต.ม. อ.กิตติ์ชวนไปติดต่อที่ห้องวีซ่าเลย แต่ห้องปิด จึงมาต่อแถวตรวจหนังสือเดินทางตามปกติ เจ้าหน้าที่ก็คัดแยกให้เรามาขอวีซ่าก่อน เจออุปสรรคอีกครั้งเมื่อเจ้าหน้าที่บอกว่าเราจะต้องจ่ายค่าวีซ่าเป็นเงิน KM ซึ่งเป็นสกุลเงินของบอสเนียเท่านั้น แต่เราถือแต่เงินยูโรและดอลลาร์สหรัฐกันมา และขณะนั้นเคาน์เตอร์แลกเงินในสนามบินปิดแล้ว! (สนามบินนานาชาติซาราเจโว ขนาดพอ ๆ กับสนามบินขอนแก่น มีรันเวย์เดียว มีที่จอดเครื่องบินได้ไม่เกินสองลำ และทั้งสนามบินมีเคาน์เตอร์แลกเงินเพียงเคาน์เตอร์เดียว!)

เจ้าหน้าที่บอกว่า จะต้องให้คนบอสเนียมาจ่ายเงินให้เรา จึงโทรติดต่อเจ้าภาพ ซึ่งตอนนี้อยู่ที่ Banja Luka กัน ถ้าจะเดินทางมาต้องใช้เวลา ๕-๖ ชั่วโมง แต่เจ้าภาพเจรจากับเจ้าหน้าที่จนได้ ว่าให้เราจ่ายค่าวีซ่าไปก่อน แล้วไปเบิกคืนกับเขา โดยพยายามหาแลกเงินกับใครก็ได้ในสนามบินไปก่อน อ.กิตติ์ถือเงินยูโร ผมถือเงินดอลลาร์สหรัฐ (ผมไม่ได้แลกเงินยูโรไป เพราะยังมีเงินดอลลาร์สหรัฐตกค้างจากการไปต่างประเทศครั้งก่อน ๆ ที่ยังไม่ได้แลกคืนอยู่ และเราไม่สามารถแลกเงิน KM จากเมืองไทยได้ ไม่มีธนาคารไหนให้แลก) เงินยูโรมีโอกาสแลกได้สูงกว่า เขาจึงพา อ.กิตติ์ เข้าไปหาแลกเงินจากคนในสนามบิน ก็ได้เงิน KM กลับมาจ่ายค่าธรรมเนียม และในที่สุดเราก็ได้วีซ่า! และได้ประทับตราเข้าเมืองได้ (เป็นอีกครั้งที่อยากใช้คำว่า ปลาบปลื้มน้ำตาไหล)

จากนั้น จึงต้องยอมจ่ายค่าแท็กซี่เป็นเงินยูโรไปก่อน (ซึ่งมีโอกาสโดนโขกสูง) เพื่อไปสถานีรถบัสที่จะไป Banja Luka อ.กิตติ์พยายามหาที่แลกเงินจนได้ โดยเจ้าหน้าที่บอกว่าสามารถแลกเงินได้ที่ที่ทำการไปรษณีย์ใกล้ ๆ นั้น

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

ระหว่างทาง บางช่วงมีลำธารสายใหญ่แทรกระหว่างกลางหน้าผาสูงชัน ซึ่งถนนที่เราผ่านนั้นอยู่บนฝั่งหนึ่งของหน้าผานั้น เป็นภาพทิวทัศน์ที่แปลกตาพอสมควร

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

ระหว่างทางรถบัสจอดแวะให้เข้าห้องน้ำที่ปั๊มน้ำมัน ทำให้ได้สังเกตป้ายราคาน้ำมัน ที่นี่น้ำมันดีเซลแพงเท่าน้ำมันเบนซิน โดยดีเซลบางชนิดแพงกว่าด้วยซ้ำ ราคาก็ตกลิตรละ ๒.๓๐ KM ก็ราว ๆ ๕๐ บาท

เกือบสี่ทุ่ม รถบัสส่งเราลงที่สถานี Banja Luka เรานั่งแท็กซี่ต่อมาที่โรงแรมเพื่อเช็กอิน รับคูปองมาทานอาหารเย็นแล้วเข้าห้องพักหลับเป็นตาย นับเวลาเดินทางตั้งแต่ออกจากกรุงเทพฯ ก็ราว ๒๘ ชั่วโมง

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

Esaan Tham Font with GSUB

ทิ้งค้างไว้จาก blog ที่แล้ว เสียนาน ก็เพิ่งได้โอกาสกลับมาทำ โครงการอักษรอีสาน ต่อ โดยหลังจากที่ได้ glyph ต่าง ๆ เรียบร้อยแล้ว ก็ถึงคราวทำเรื่องกฎการแสดงข้อความ

ดังที่ได้อธิบายไว้ ว่าอักษรธรรมในยูนิโค้ดจะลงรหัสในข้อความในลำดับที่เรียกว่า logical order ตามแบบอักษรอินเดีย (ซึ่งจากการที่โดนกระแนะกระแหนบ่อย ๆ ว่าอักษรไทยกับลาวเป็น ข้อยกเว้น ของ logical order สำหรับอักษรในตระกูลเดียวกัน ราวกับว่าสองอักษรนี้ไม่ logical กระนั้น ก็ทำให้ผมอยากจะเรียก logical order เสียใหม่ว่า phonetic order) ซึ่งลำดับการเก็บแบบ logical order หรือ phonetic order นี้ แตกต่างจากลำดับที่แสดงผลจริงซึ่งเรียกว่า visual order ทำให้ต้องมีการเรียงลำดับ glyph เสียใหม่ขณะแสดงผล

เนื่องจากทางเลือกอื่น คือการรอให้ rendering engine รองรับอักษรธรรม หรือการรอให้ไมโครซอฟท์จัดทำข้อกำหนดของการแสดงอักษรธรรมด้วย OpenType เป็นเรื่องที่ไม่สามารถสำเร็จได้ในเวลาอันสั้น ผมจึงจำเป็นต้องใช้วิธีสร้างกฎ GSUB ให้สามารถวาดแสดงได้ในตัวเองโดยไม่พึ่ง preprocessing ใน rendering engine เลย

โจทย์หนักที่สุดคือการสลับลำดับสระหน้า เพราะ GSUB ไม่มีรูปแบบกฎที่ซับซ้อนพอที่จะเขียนการสลับ AB เป็น BA ได้ เครื่องมือที่มีให้คือ:

• Multiple substitution คือการแทน glyph 1 glyph ด้วย glyph string เช่น A → XYZ
• Ligature substitution คือการแทน glyph string ด้วย glyph 1 glyph เช่น XYZ → A
• Contextual substitution คือการกำหนด substitution (multiple หรือ ligature ข้างต้น) ที่จะกระทำเมื่อพบแพตเทิร์นที่กำหนด เช่น ถ้าพบ abc ให้ใช้กฎ P ที่ตำแหน่ง glyph ที่ 2 เป็นต้น

ยังมี substitution แบบอื่นอีกพอประมาณ แต่ก็ไม่ได้มีความสามารถมากไปกว่านี้ ซึ่งจะพบว่าการเขียนกฎง่าย ๆ แค่ AB → BA นั้น ไม่ใช่เรื่องง่ายเอาเสียเลย แต่โชคดีที่เผอิญไปได้เคล็ดวิชาจากเพื่อนชาวพม่ามาว่าเขามีลูกสูตรกันแบบนี้:

AB → BAB [Mul. A → BA]
BAB → BA [Lig. AB → A]

คือใช้ contextual 2 กฎ, multiple 1 กฎ และ ligature อีก 1 กฎ โดย contextual นั้นสามารถกำหนดแพตเทิร์นเป็นคลาสได้ แต่ multiple และ ligature นั้น ต้องลิสต์ทุก combination แบบเรียงตัวเท่านั้น

เนื่องจากรูปแบบระหว่างทาง (คือ BAB ในตัวอย่างข้างต้น) นั้นสุ่มเสี่ยงที่จะไปชนกับข้อความจริง ผมจึงดัดแปลงกฎเสียใหม่เป็นแบบนี้:

AB → BAxB [Mul. A → BAx]
BAxB → BA [Lig. AxB → A]

โดย x เป็น dummy ตัวหนึ่งที่ใส่เข้ามาเพื่อป้องกันการ match กับข้อความจริง จะเลือก glyph อะไรก็ได้ที่ไม่มีที่ใช้ในข้อความจริง

และในบางกฎ ก็เหมาะที่จะทำข้างหลังก่อน ซึ่งจะทำให้ลดจำนวนกฎ contextual ลงได้:

AB → AxBA [Mul. B → xBA]
AxBA → BA [Lig. AxB → B]

ได้สูตรแบบนี้แล้ว ผมก็มานั่งออกแบบกฎ GSUB สำหรับอักษรธรรมอีสานได้แล้ว โดยหลังจากประมวลอักขรวิธีต่าง ๆ แล้ว ก็สรุปเป็นขั้นตอนการทำงานดังนี้:

1. สลับลำดับ ไม้อังแล่น (ง สะกดเหนือพยัญชนะ) ในภาษาบาลี

     NGA-above + SAKOT + Cons --> Cons + NGA-above
   

2. เปลี่ยนพยัญชนะเป็นรูปตัวห้อย/ตัวเฟื้องเมื่อตามหลัง SAKOT

     SAKOT + Cons --> Cons.sub
   

3. สลับลำดับสระหน้า

     Cons + [sub|medial-RA] + LV --> LV + Cons + [sub|medial-RA]
   

4. สลับลำดับ ระวง

     Cons + medial-RA --> medial-RA + Cons
   

5. จัดการรูปย่อ น + า แบบซับซ้อน

     NA + {sub|tone|UV|BV} + AA --> NAA + {sub|tone|UV|BV}
   

6. จัดการรูปย่อทั่วไป

     NA + AA --> NAA
     WA + tall-AA --> WAA
   

หลังจากได้ลำดับกฎแล้ว ก็มา implement กฎแต่ละกฎด้วยสูตรข้างต้น โดยมีเคล็ดในการลดจำนวนกฎอยู่ว่า ให้พยายามเลือกเซ็ตที่ใหญ่ที่สุด (เช่น พยัญชนะ) เป็นตัวแปลง แล้วไปลิสต์รายการในตาราง multiple/ligature substitution เป็นหมวด ๆ เอา จะทำให้ได้จำนวนหมวดน้อย จัดการในระดับบนได้ง่าย ถ้าเราไปเลือกแปลงเซ็ตเล็ก (เช่น สระหน้า) แทน จะทำให้ได้หมวดเล็ก ๆ จำนวนมาก จำนวน contextual substitution มาก จัดการในระดับบนได้ลำบาก

หมายเหตุ: แม้จะลดปริมาณกฎลงแล้ว แต่ก็ยังมากอยู่ดี ทำใน fontforge อย่างเดียวไม่ไหว งานนี้สำเร็จได้ด้วย vim ครับ ;-)

ทำฟอนต์เสร็จแล้ว ก็ทำ หน้าทดสอบฟอนต์ เอาไว้ด้วย โดยฝังฟอนต์ลงในเว็บเลย เปิดด้วย Firefox/Iceweasel ตั้งแต่รุ่น 4 ขึ้นไปได้ผลดี ส่วน Chrome/Chromium หรือเบราว์เซอร์อื่นที่ใช้ WebKit (เช่น Epiphany, Midori) นั้น แสดงอักษรได้อยู่ แต่กฎ GSUB จะไม่ทำงาน ทำให้ลำดับการแสดงไม่ใช่ลำดับสำหรับมนุษย์อ่าน ส่วน IE ไม่มีให้ทดสอบครับ