DebConf11 Last Days

เขียน blog เกี่ยวกับ DebConf 11 มาได้ ๔ ตอน (ตอนที่ ๐, ตอนที่ ๑, ตอนที่ ๒, ตอนที่ ๓) ก็มีอันต้องหยุดเขียน เพราะต้องง่วนแก้ปัญหา debianclub.org หนึ่ง (ซึ่งเป็น SSH session ที่ทรมานมาก ด้วยระยะทางที่ไกล) และพยายามเข้า hacklab ทำงานอีกหนึ่ง ก็ขอมาสรุปทีเดียวละกัน

เกี่ยวกับบอสเนีย

• บอสเนียผ่านศึกสงครามมาหลายครั้ง ถูกยึดครองโดยจักรวรรดิโรมัน, จักรวรรดิออตโตมาน, จักรวรรดิออสเตรีย-ฮังการี ถูกโครเอเชียและชาวเซิร์บถล่มในสงครามโลกครั้งที่ ๒ และยังมีสงครามฆ่าล้างเผ่าพันธุ์ที่เกิดขึ้นล่าสุดอีกด้วย
• ผลของสงคราม ทำให้เมือง Banja Luka มีประชากรผู้หญิงมากเป็น ๗ เท่าของชาย เพราะผู้ชายต้องไปรบและตายในสนามรบเสียเยอะ
• สมัยโรมัน โรมันยึดครอง Banja Luka โดยไม่ได้บริหารอะไรเลย เพราะชัยภูมิเป็นหุบเขา เข้าถึงลำบาก มีเพียงการตัดถนนเลียบแม่น้ำที่เป็นพรมแดนธรรมชาติกับโครเอเชียเท่านั้น
• เมื่อคริสตศาสนาเข้าสู่ยุโรป พื้นที่ยุโรปตะวันออกนับถือนิกายออร์โทดอกซ์เป็นหลัก ในขณะที่ทางยุโรปตะวันตกจะนับถือนิกายแคทอลิก แต่บอสเนียมีนิกายของตนเองต่างหาก นิกายนี้เชื่อว่าพระเยซูคือมนุษย์คนหนึ่งซึ่งเป็นแบบอย่างในการดำรงชีวิต ไม่ได้เป็นบุตรพระเจ้า และจะมีนักบวชอาวุโสคอยสืบทอดคำสอนของพระเยซู เป็นหลักของบ้านเมือง ส่วนกษัตริย์นั้น เพื่อความอยู่รอดท่ามกลางขั้วอำนาจต่าง ๆ บางครั้งต้องประกาศพระองค์เป็นแคทอลิกบ้าง ออร์โทดอกซ์บ้าง แล้วแต่รัชสมัย แม้ที่จริงแล้วจะนับถือนิกายของบอสเนียเอง
• การถูกจักรวรรดิออตโตมานซึ่งเป็นชาวเติร์กยึดครอง ทำให้ประชาชนถูกบังคับให้เข้ารีตเป็นมุสลิมมากมาย และมีการสร้างมัสยิด เกิดชุมชนมุสลิมกระจายเป็นแห่ง ๆ ปะปนกับคริสต์ทั้งแคทอลิกและออร์โทดอกซ์
• อักษรหลัก ๆ ที่ใช้มีสองชนิด คืออักษรละติน (จากรากฐานด้านแคทอลิก) และอักษรซีริลลิก (จากรากฐานด้านออร์โทดอกซ์) และยังมีบ้างที่ใช้อักษรกรีกด้วย ส่วนภาษาพูดก็เป็นภาษาเซิร์บ
• Banja Luka เป็นเมืองที่ใหญ่เป็นอันดับสองของบอสเนีย เป็นเมืองหลักของเขตการปกครองที่เรียกว่า Republika Srpska ซึ่งแยกเป็นคนละส่วนกับส่วนที่เหลือของประเทศ มีธงชาติแยกต่างหากเป็นของตนเอง แต่เมืองหลวงยังถือว่าอยู่ที่ Sarajevo ที่เป็นเมืองหลวงของทั้งประเทศ
• ที่ Sarajevo มีสะพานแห่งหนึ่งชื่อ Latin Bridge เป็นสถานที่สำคัญในประวัติศาสตร์โลก คือเป็นจุดที่ Archduke Franz Ferdinand รัชทายาทแห่งออสเตรียถูกลอบปลงพระชนม์ และเป็นชนวนไปสู่สงครามโลกครั้งที่ ๑ ในเวลาต่อมา
• สภาพบ้านเมืองของบอสเนีย ถือว่ามีการพัฒนาพอประมาณ แต่ไม่มากเท่าประเทศในยุโรปตะวันตก ก็คงเป็นมาตรฐานของยุโรปตะวันออกทั่วไป ยังมีถนนปุปะ ทางลูกรังให้เห็นประปราย แต่ที่น่าสังเกตมากคือมีการปลูกข้าวโพดกันอย่างจริงจัง ไม่ใช่แค่ในไร่ แม้กระทั่งในบริเวณบ้านก็จะมีแปลงข้าวโพดให้เห็นในบ้านทั่วไป หรืออย่างน้อยก็ปลูกเป็นแนวกั้นอาณาเขต แล้วจึงมีการปลูกไม้ดอกไม้ผลอย่างอื่นแซมเหมือนบ้านทั่วไป

เนื้อหา DebConf

ถัดจาก blog ก่อน ๆ ก็มีเนื้อหาที่น่าสนใจที่ผมได้เข้าฟังดังนี้:

• AppRecommender เป็นโครงการสร้างระบบแนะนำซอฟต์แวร์โดยผู้ใช้ด้วยกันเอง (ในลักษณะ ผู้ใช้ที่โหลดโปรแกรมนี้ มักจะโหลดโปรแกรมนั้นด้วย) โดยได้สร้างเว็บ survey เพื่อเก็บรวบรวมข้อมูล และสร้าง เว็บทดสอบการแนะนำซอฟต์แวร์
• AltosUI เป็นการเล่าประสบการณ์ของ Bdale Garbee และ Keith Packard เกี่ยวกับการทำ UI สำหรับติดตามและควบคุมการปล่อยจรวด โดยทั้งสองเป็นนักพัฒนาที่คร่ำหวอดด้านซอฟต์แวร์ระบบ แต่ไม่มีประสบการณ์เรื่องซอฟต์แวร์ UI สักเท่าไร แต่ก็ได้ทดลองทำ โดยเริ่มจากใช้ภาษาซีและ GTK+ ซึ่งปรากฏว่าพบปัญหามากมาย เช่น เขียนยากกว่าที่คิด, ระบบ GObject ที่ไม่ใช่การรองรับในระดับ syntax และจะพบ warning เกี่ยวกับ type error เมื่อ run-time เท่านั้น, ต้องอาศัยความรู้ในระดับโครงสร้างทั้งหมดเพียงเพื่อเขียนโปรแกรมง่าย ๆ ฯลฯ สุดท้าย เมื่อโครงการมีผู้สนใจมากจนต้องเปิดบริการเชิงพาณิชย์ และต้องรองรับผู้ใช้ Windows และ Mac ด้วย จึงเลือกใช้ภาษา Java แทน ซึ่งปรากฏว่าง่ายกว่ากันมาก ไม่มีปัญหาต่าง ๆ ที่ว่า ตัวโครงการอยู่ที่ gag.com/rockets
• ระบบ Autobuilder ของ Debian ซึ่งใช้ build แพกเกจสำหรับสถาปัตยกรรมต่าง ๆ ที่ Debian รองรับโดยอัตโนมัติ แบ่งเป็น 3 ชั้น คือ wanna-build เป็นระบบประสานงานการขอ build และจัดคิวผ่านฐานข้อมูล, buildd เป็น daemon สำหรับ build, และ sbuild เป็นระบบ chroot ที่ใช้ build (คล้าย pbuilder)
• รายงานผลการปรับระบบใน debian-mentors เมื่อปลายปีที่แล้ว มีการปรับระบบใน debian-mentors เพื่อให้ RFS ต่าง ๆ ได้รับการตอบสนองดีขึ้น โดยกำหนดให้แต่ละ RFS ต้องได้รับการตอบสนองภายใน ๔ วัน มิฉะนั้นจะเริ่มมีการรายงาน เพื่อให้ DD ที่สนใจจะช่วยได้มองเห็นทันที นอกจากนี้ยังมีการกำหนดให้ sponsoree มีการรีวิวกันเองด้วย ซึ่งผลที่ได้คือเหลือ RFS ตกค้างน้อยลง แต่ก็มีบางเดือนที่ตัวเลขตกค้างเพิ่มขึ้นบ้าง นอกจากนี้ ก็ได้เริ่มพัฒนา expo.debian.net ขึ้นใช้แทน mentors.debian.net ซึ่งนอกจากหน้าตาที่สวยขึ้นแล้ว ยังอาจมีความสามารถอื่น ๆ ที่จะช่วยอำนวยความสะดวกในการรีวิว เช่น การแตกแฟ้มบางแฟ้มที่สำคัญขึ้นมาแสดงบนเว็บ มีข้อเสนอแนะว่าอาจจะกระจายงานบางส่วนออกไปยัง mailing list ของทีมเฉพาะด้านด้วย (ซึ่งผมคิดว่าก็มีการทำเป็นปกติอยู่แล้ว)
• FreedomBox เป็นโครงการสร้างกล่องอุปกรณ์เล็ก ๆ ที่ทำหน้าที่เซิร์ฟเวอร์ส่วนตัวเพื่อการใช้เครือข่ายแบบรักษาความเป็นส่วนตัวของผู้ใช้ โดยทำงานผ่าน mesh network มีการก่อตั้ง FreedomBox Foundation ใช้ DreamPlug เป็น reference implementation เริ่มแรก และใน DebConf 11 ก็พยายามแฮ็กกันเพื่อสร้าง user-space tools สำหรับสั่งงาน
• Language Skill Exchange ไหน ๆ ก็มีคนหลายชาติมารวมกัน ก็เลยมีการเสนอทำกิจกรรมแลกเปลี่ยนความรู้ด้านภาษา โดยมีภาษาอิตาลี, สเปน, ไทย, จีน (แมนดาริน, หมิ่นหนาน), อาหรับ, รัสเซีย, เซิร์บ, โครเอเชีย, บอสเนีย, เยอรมัน, ฝรั่งเศส ก็พอสรุปคร่าว ๆ ว่า มีภาษาไทย, จีน และอาหรับที่ไม่มีกริยาช่วย และภาษาส่วนใหญ่ใช้คำขยายต่อท้ายคำหลัก (ไม่ใช่ใช้ข้างหน้าแบบภาษาอังกฤษและจีน)
• เสนอตัวเจ้าภาพ DebConf 13 ถัดจาก DebConf 12 ที่นิคารากัว ก็มีผู้เสนอตัวเป็นเจ้าภาพ DebConf 13 หลายประเทศ ได้แก่ เวียนนา/ออสเตรีย, ลัตเวีย, สวิตเซอร์แลนด์, อิสตันบูล, กรีซ, สหราชอาณาจักร, WestLafayette/US (เมืองที่ Ian Murdock อยู่ขณะที่ประกาศตั้งโครงการ Debian และในปีที่จัด DebConf 13 นั้น Debian จะมีอายุครบ ๒๐ ปีพอดี), เบอร์ลิน/เยอรมนี ปิดท้ายด้วยไอเดียขำ ๆ จาก H01ger ว่า DebConf 14 อาจจะจัดที่ Martinique ซึ่งเป็นเกาะของฝรั่งเศสในอเมริกาใต้ ซึ่งก็ถือว่ายังอยู่ใน EU คนยุโรปไม่ต้องขอวีซ่า, และ DebConf 18 อาจจะจัดบนเรือเลยดีไหม? โดยล่องเรือไปรับ DD ตามท่าต่าง ๆ แล้วก็ประชุมและแฮ็กกันบนเรือนั่นแหละ แต่ปัญหาหลักคืออินเทอร์เน็ต แต่กว่าจะถึงปีนั้น อาจจะมีเทคโนโลยีรองรับแล้วก็ได้! (ทุกคนชี้ไปที่ Bdale!)

บรรยากาศทั่วไปของ DebConf

• ผมได้พบกับ DD หลายคนที่เคยติดต่อกันแบบออนไลน์มาก่อน เช่น Martin Würtele (maxx) ซึ่งเป็น AM (application manager) ที่สอบผมตอนสมัครเข้าเป็น DD, Martin Michlmayr (tmb) อดีต DPL ที่เคยมางาน AOSS ที่จีน (แต่ผมไม่ได้ไป) และสนใจกิจกรรมโอเพนซอร์สในไทย, Raphaël Hertzog ผู้สร้าง facebook page ของ Debian และดึงผมเข้าร่วมเป็น admin และยังได้พบกับคนอื่น ๆ ที่ยังไม่เคยติดต่อกันมาก่อนอีกหลายคน
• ผมได้สัมผัสกับบรรยากาศของ gift culture ที่ทุกคนล้วนตื่นตัวที่จะมีส่วนร่วม แม้แต่การดำเนินการประชุมยังมาจากอาสาสมัครผู้ฟังในห้องนั่นแหละ ไม่ต้องมีเจ้าภาพใด ๆ การอภิปรายแบบสร้างสรรค์ที่คึกคัก การรับอาสาทำงานอย่างเต็มใจ ซึ่งบรรยากาศระดับนี้ค่อนข้างหายากที่เมืองไทย จนผมเองก็รู้สึกไม่พร้อมที่จะมีส่วนร่วมเท่าไร ได้แต่ตั้งใจว่าต้องกลับไปเตรียมตัว ไปฝึกฝนให้มากกว่านี้
• ได้พบว่าบางครั้งไม่ใช่แค่เราที่กลัวฝรั่ง ฝรั่งบางคนก็กลัวที่จะนั่งคุยกับคนเอเชียเหมือนกัน เพราะคนเอเชียมักมีบุคลิกขรึม ๆ เขาก็ไม่รู้จะเปิดปากพูดด้วยเรื่องอะไร หรือชวนคุยแล้วเขาจะต้องรับภาระพูดเป็นต่อยหอยฝ่ายเดียวหรือเปล่า บางครั้งจึงต้องมีการ break the ice ด้วยการเป็นฝ่ายชวนเขาคุยเสียหน่อย ซึ่งถ้าคิดประเด็นแรกได้แล้ว ก็จะสามารถสนทนาลื่นไหลต่อไปได้
• ได้พบว่าข่าวการเมืองไทยค่อนข้างฉาวโฉ่ คนทั่วโลกเขารู้รายละเอียดพอสมควรว่าเหลือง-แดงคิดอะไร ทำอะไร เรื่องนี้กลายเป็นประเด็นพูดคุยบนโต๊ะอาหารได้เลย (ซึ่งผมเองไม่ยอมเป็นฝ่ายเปิดประเด็นแน่)
• OpenStreetMap ที่บอสเนียข้อมูลค่อนข้างหนาแน่น แค่พื้นที่แคบ ๆ ข้อมูลก็เกินขนาดที่ API รองรับได้แล้ว

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 เป็นฐาน