The Death of LTN Webboard

เห็น vee เขียนถึงความเป็นไปของ LTN ใน blog เรื่อง google reader เลยถือโอกาสเขียนถึงเรื่องนี้มั่ง

การตายลงของเว็บบอร์ด LTN นั้น ก็คงเป็นอย่างที่ vee บอกไว้ ว่าคนหันมาเล่น blog กันหมด ซึ่งการเกิดของ Planet TLWG คงไม่ใช่แค่การปรับตัวเท่านั้น แต่เป็นสาเหตุหนึ่งของการเงียบลงของเว็บบอร์ดเลยแหละ หลังจากที่คนหันมาเล่าประเด็นต่างๆ ใน blog แทน แต่ทำไมถึงเกิดแนวโน้มอย่างนั้นได้ล่ะ?

ในส่วนของคนอื่น ผมไม่อาจสรุป แต่ในส่วนของผม มีสาเหตุสองอย่าง

อย่างแรกคือไม่มีเวลา หลังจากออกมาทำงานเลี้ยงตัวเอง ก็จะปรากฏว่างานเหล่านั้นเรียกร้องความเป็นมืออาชีพของเรา ถ้าช่วงไหนมีงานว่าจ้างเข้ามา ก็ต้องจัดลำดับความสำคัญของงานให้กับงานที่ว่าจ้างนั้นก่อนงานอาสาสมัคร ทั้งๆ ที่อยากทำตรงข้ามมากกว่า เพราะงานว่าจ้างที่มีแต่ความต้องการแบบ proprietary มันน่าเบื่อ อีกทั้งการมาอยู่กับบ้าน ก็จะมีธุระทางบ้านที่เรียกร้องความช่วยเหลือของเราอยู่เนืองๆ เช่นกัน ทั้งนี้ ยังไม่นับรวมแรงเสียดทานของคนรอบข้าง ที่ไม่เห็นด้วยกับการทำงานที่ปราศจากรายได้ ทั้งหมดนี้ก็ทำให้งานอาสาสมัครต้องถูกจัดไว้ท้ายๆ ไว้ทำเมื่อมี "เวลาว่าง" จริงๆ เท่านั้น และเนื่องจากการแจมเว็บบอร์ดหลักๆ ของผม ก็เพื่อพูดคุยเกี่ยวกับงานพัฒนา ในเมื่อเวลาสำหรับงานพัฒนามีน้อยลง การพูดคุยก็น้อยลงตามไปด้วย อาจจะมีบ้างบางช่วงที่พยายามรักษาการเชื่อมโยงกับผู้คนไว้ ด้วยการคุยในบอร์ด general หรือ etc บ้าง แต่ก็ไม่สามารถตามประเด็นที่ยืดยาวได้มากนัก ในที่สุด ช่วงหลังก็เหลือแต่การโพสต์ software release ในบอร์ด devel เท่านั้น

สาเหตุอย่างที่สอง คือความเหนื่อยหน่ายต่อความเป็น "สาธารณะ" ของ LTN จริงอยู่ การรักษาเสรีภาพต่างๆ ของผู้เข้าร่วม เป็นหัวใจของชุมชนอินเทอร์เน็ตและโอเพนซอร์ส แต่ความสุดโต่งก็ทำให้เกิดโสหุ้ยต่อผู้ดูแลเว็บอย่างมาก การเริ่มใช้มาตรการแต่ละอย่าง แม้จะเพื่อประโยชน์ของผู้เข้าร่วม เช่น การป้องกัน spam ก็ไม่ใช่เรื่องง่าย หรือจะพูดในฐานะของผู้เข้าร่วม ช่วงที่เนื้อหาของเว็บบอร์ดมีแต่การโต้เถียงกันยืดยาวโดยไม่มีทีท่าจะคุยกันรู้เรื่อง ก็เป็นช่วงที่น่าเหนื่อยหน่าย มันเกิดบ่อยจนกระทั่งผมเลือกจะใช้เสรีภาพที่เหลืออยู่ที่ผมจะใช้ได้ คือเลิกอ่านและเลิกต่อล้อต่อเถียงเสีย แล้วไปใช้หนทางที่ผมสามารถควบคุมอะไรได้อย่างอิสระ คือเขียนลง blog ของตัวเอง

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

ก็ปรากฏว่าแนวโน้มของ LTN โดยรวม ก็เกิดคล้ายๆ กัน ผมไม่รู้สาเหตุของคนอื่นๆ บางคนก็บอกว่า LTN ถึงกาลหมดอายุขัยแล้ว บางคนสละเรือไปสร้างชุมชนอื่น หรือจะพูดแบบนักวิเคราะห์หน่อยก็อาจจะบอกว่า เพราะโลกแบนลง :P ปัจเจกบุคคลมีความสำคัญมากขึ้น ซึ่ง blog และ planet ตอบสนองแนวโน้มได้ดีกว่า :P ผมเองก็ยังไม่ชัดเจน ว่าเห็นยังไงกับ LTN ส่วนหนึ่งก็เสียดายชุมชนนักพัฒนาที่เคยเป็นชุมชนเดียวที่ทำให้เกิด contribution ต่อ FOSS อย่างแท้จริง อีกส่วนหนึ่งก็ยอมรับข้อจำกัดของ LTN ว่ามันคงหาความคล่องตัวได้ยาก

Planet คงจะกลายเป็นส่วนเดียวของ LTN ที่ยังมีชีวิตอยู่ ซึ่งถ้าจะว่าไป มันก็เป็นช่องทางหนึ่งที่ใช้กันในชุมชนนักพัฒนาทั่วไป เช่น GNOME, Debian, Ubuntu โดยบางครั้งมีการตอบ blog กันไปมาผ่าน planet ด้วย (blog ของ Debian Developer บางคน เช่น ของ Joey Hess ไม่เปิดรับ comment ก็ด้วยสาเหตุที่ต้องการให้คนอื่น ตอบ blog ด้วย blog นี่แหละ)

นั่นถือเป็นช่องทางสำหรับคนที่เป็นสมาชิก planet น่ะนะ แล้วก็อาจจะมี IRC ที่ยังเคลื่อนไหวอยู่ ส่วนช่องทางสำหรับผู้ผ่านมาอย่าง webboard ถ้าจะเปิดไว้ มันก็คงร้าง มีแต่ spam รกครึ้มแบบที่มันเป็นในช่วงก่อนจะปิดปรับปรุงเว็บน่ะแหละ นอกเสียจากจะสร้างความสมดุลระหว่างแรงงานที่ลงมือทำ กับความต้องการของคนในชุมชนได้

iceweasel-libthai 2.0.0.2

iceweasel 2.0.0.1 ใน debian เพิ่งแก้บั๊กไป ก็มีรุ่น 2.0.0.2 ออกตาม firefox® มาติดๆ - -' ไหนๆ ก็ไหนๆ วันนี้ตกลงใจว่าจะพักงานอื่นเพื่อไล่แปล GNOME 2.18 ก่อน tarballs due เที่ยงคืนนี้ ก็ใช้ CPU ที่ว่างอยู่ให้เป็นประโยชน์ด้วย

ผลคือ iceweasel-libthai 2.0.0.2 ทั้ง amd64 และ i386 ที่ LTN apt ครับผม (พอดีไม่เจอ Neutron ประกอบกับ CPU ว่างอยู่ เลย build เองเสีย แต่ก็เล่นเอารออัปโหลดเงกเหมือนกัน)

xulrunner-libthai Fix for Liferea

อีกนิดกับ xulrunner-libthai คือไปพบว่า Liferea (โปรแกรมอ่าน feed แบบ GTK+) ที่ใช้ xulrunner backend นั้น มีปัญหา unresolved symbol กับ mozlibthai component และเมื่อเร็วๆ นี้ debian maintainer ได้ติดสินใจ drop gtkhtml backend ที่อาจใช้แก้ขัดแทนได้ไปเรียบร้อย เพราะมันมีปัญหา crash บ่อยใน amd64 (ผมก็เจอบ่อยเหมือนกัน)

ก็เลยเป็นการจี้ให้แก้แพตช์ xulrunner-libthai เพื่อให้ liferea ใช้การได้ ไหนๆ ก็เพิ่งจับโค้ด iceweasel มาหมาดๆ ก็เลยถือโอกาสแก้ xulrunner ด้วย โดยอัปโหลดรุ่น 1.8.0.9-1thai2 เรียบร้อยที่ LTN apt พร้อม i386 deb จากบริการ Neutron's human buildd ;-) ขอบคุณอีกครั้งหนึ่ง

Fox and Weasel

หลังจากที่ขาดการติดต่อกับ Ubuntu developer ที่เคยเป็นพี่เลี้ยงให้ไปเสียนาน (เมลไปแล้วเขาไม่ว่างตอบ) นึกว่าแผนการ update แพกเกจใน feisty จะเป็นหมันเสียแล้ว ปรากฏว่าเมื่อปลายอาทิตย์ที่แล้ว Alexander Sack ซึ่งเป็น maintainer คนใหม่ของ firefox ใน Ubuntu ได้ติดต่อมาเรื่อง patch ภาษาไทย ก็เลยถือโอกาสขอ update แพกเกจต่างๆ เสียเลย จะได้แค่ไหนยังไม่รู้ เพราะ feisty กำลัง freeze อยู่

เรื่องแรกคือ Malone 43393 เกี่ยวกับสระลอยใน firefox® อันเนื่องมาจาก priority ที่สูงเกินไปของ TlwgMono จึงเสนอให้ sync thaifonts-scalable 0.4.5-2 จาก debian etch ซึ่งแก้ปัญหานี้ไปแล้ว

เรื่องถัดไปคือ การ update patch ตัดคำภาษาไทยใน firefox ให้แยก mozlibthai component ออกมา ตามวิธีที่ได้รับการชี้แนะจาก Mike Hommey ซึ่งเป็น debian maintainer และได้ update patch ใน Mozilla Bug #7969 พร้อมกับ back port patch มาใช้ใน LTN apt มาระยะหนึ่ง (xulrunner-libthai และ iceweasel-libthai) โดยมีการเสนอ patch ใน Debian Bug #366306 ไว้ด้วย (ยาวจังเนาะ งานยืดยาวพวกนี้จะหมดไป ถ้า Mozilla รับ patch เสียที)

กับอีกเรื่องหนึ่งที่ยังคั่งค้าง คือการ update libthai พร้อม dependency ใหม่คือ libdatrie ด้วย ซึ่งสถานะล่าสุดคือ libdatrie เข้าไปอยู่ใน sid ได้ราว 2 เดือนแล้ว แต่ libthai ยังไม่ได้ upload ยังคงค้างอยู่ที่ LTN apt อยู่ แต่เนื่องจาก libthai ตัวใหม่นี้ เป็นการรื้อ engine ตัดคำเขียนใหม่ อาจจะเป็นการเปลี่ยนแปลงที่มากเกินไปสำหรับช่วง freeze ของทั้ง etch และ feisty จึงคิดว่าไม่ซีเรียสมาก ไว้ไปเริ่มหลัง etch, feisty ได้ ในระหว่างนี้ ผู้ใช้ที่ต้องการใช้ตัวใหม่ ก็ใช้จาก LTN apt ได้ ซึ่งเท่าที่ผ่านมา ก็ดูใช้การได้ดีอยู่ มี bug fix ไปพอสมควรแล้ว

ในอีกทางหนึ่ง iceweasel ใน debian ก็มี release ใหม่ ก็เลยถือโอกาส patch และ build เข้า LTN apt ต่อเลย

สรุปว่า เมื่อวานนี้เลยเป็นวันของจิ้งจอกกับเพียงพอน (พยายามตั้งชื่อหัวข้อ blog ให้คล้าย "Cats and Dogs" อยู่) โดยซุกงานอื่นไว้ก่อน มา build firefox ตัวใหม่ให้ feisty (เอาพักไว้ที่ homepage) แล้วติดต่อ Ubuntu ขอ upload ตามด้วยการ build iceweasel สำหรับ LTN apt โดยมี Neutron ช่วย build i386 deb ให้อีกเช่นเคย การ build นั้นไม่นานเท่าไรหลังจากมีเครื่องใหม่ (40 นาที จากเดิม 5 ชั่วโมง) แต่ตอน upload นี่ซิ เป็นหลายชั่วโมงเลยกว่าจะหมด ดังนั้น ที่ Neutron แบ่ง i386 arch ไปทำ ก็ช่วยแบ่งเบาได้มากทีเดียว

The Dead Debian Club

ยังเคลียร์งานไม่จบครับ เลยไม่ได้ไปดูแล debianclub เสียนานเลย แม้เมื่อราววันจันทร์จะได้รับข่าวร้ายจาก kitty ว่าฮาร์ดดิสก์เจ๊ง จนไม่สามารถกู้ข้อมูลกลับมาได้ ก็ยังไม่สามารถไปเซ็ตเว็บใหม่ได้

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

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

ต้องขออภัยสมาชิกและผู้ติดตามอ่าน debianclub ทุกท่าน สำหรับการสะดุดในครั้งนี้ บทความเก่าๆ จะพยายามไล่ขุดจาก google cache มาให้ได้มากที่สุด และในระหว่างนี้ ก็อยากจะขอข้อเสนอแนะจากทุกท่าน ว่าอยากให้ debianclub ทำอะไรอีกไหม นอกจาก tip & trick แบบเข้มข้นที่ได้เขียนกันไปในช่วง 3 เดือนที่ผ่านมา (ขอขอบคุณนักเขียนทุกท่านที่ได้ร่วมกันแบ่งปันความรู้) รวมทั้งระบบการดูแลเว็บที่ไม่ให้ทีมงานเล็กๆ ต้องโหลดมาก ให้เว็บเดินไปได้ด้วยตัวเอง

Debian vs Ubuntu?

เห็นบ่อยละ เกี่ยวกับที่มีคนเขียนแหย่ Debian vs Ubuntu บ่อยๆ พักหลังเจอหลายคนก็ชอบยุให้เลิกทำงานกับ debian แล้วมาทำงานกับ ubuntu แทน เลยทำให้อยากเขียนถึงเรื่องนี้ในมุมมองของผมบ้าง

ศึกระหว่าง debian กับ ubuntu ในความเห็นผม เป็นศึกระหว่าง user เป็นหลักครับ แต่ในส่วนของนักพัฒนา หลายต่อหลายส่วนมีการพึ่งพากันไปมาแบบวงศาคณาญาติ

ผู้ใช้บางคนชอบกัด debian บ่อยๆ ว่าซอฟต์แวร์เก่ากว่า ubuntu แต่ความจริงก็คือ แพกเกจใน ubuntu หลายตัวที่ว่าใหม่ๆ ก็มา sync เอาไปจาก debian นั่นแหละ บางครั้งเป็น experimental ซึ่งยังไม่เข้า unstable สรุปว่า "ความใหม่สด" ส่วนหนึ่งของ ubuntu ก็มาจากความ "ใหม่สด" ของ debian ที่ทำงานอยู่เบื้องหลังนั่นเอง ใครอยากรู้ความเป็นไป นั่งอ่าน changelog ของ ubuntu ผ่าน apt-listchanges สักพักจะพอเห็นภาพ

ในทางกลับกัน ubuntu developer หลายคนก็พยายาม merge การเปลี่ยนแปลงต่างๆ จาก ubuntu กลับเข้าใน debian เพื่อลดภาระในการ sync เหมือนกัน ก็นับเป็นส่วนหนึ่งของ "contribution" ที่ ubuntu มีต่อ debian ในฐานะที่ debian เป็น "ต้นน้ำ"

ว่ากันตาม logic แล้ว การจับ ubuntu กับ debian มาแข่งกัน ก็เหมือนกับเอา Red Hat มาแข่งกับ GNOME ที่เป็นต้นน้ำ ซึ่งจะดูแปลกๆ อยู่

แต่ก็ไม่ใช่ว่าไม่มีประเด็นให้เปรียบเทียบในฐานะของความเป็น distro ของทั้งสอง

debian นั้น ไม่ได้เน้นการ release สักเท่าไร ผู้ใช้ส่วนใหญ่จะ install ครั้งเดียว แล้ว upgrade แบบต่อเนื่องไปเรื่อยๆ ซึ่งจะทำให้ได้ซอฟต์แวร์ใหม่ใช้อยู่ตลอดเวลา แต่ช่วงเวลาแห่งความทรมานจะเริ่มเมื่อจะเริ่มมีการ release ต่างหาก เพราะ debian ไม่ได้มีนโยบาย release ตามกำหนดเวลา แต่จะ release โดยใช้จำนวน release critical bug (RC bug) เป็นเกณฑ์ ว่าจะต้องต่ำกว่าที่กำหนด จึงจะ release ได้ ซึ่งในระหว่างนั้นจะมีการ freeze ไม่ให้ update อะไรโดยไม่ใช่ bug fix เพื่อป้องกันการเพิ่มขึ้นของ RC bug แต่เนื่องจาก debian มีขนาดใหญ่มหึมา การลด RC bug ให้ต่ำกว่าเกณฑ์จึงไม่ใช่เรื่องง่าย และมักทำให้ช่วงเวลาของการ freeze ยาวนาน จนกระทั่งเมื่อ release ออกมา แพกเกจต่างๆ ก็ล้าสมัยไปแล้ว (แต่ไม่นับ experimental ซึ่งจะถูกใช้ update แทน unstable อย่างหนักหน่วงในช่วง freeze นี้)

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

แต่ความไม่เข้าใจธรรมชาติที่ว่านี้ของคนส่วนใหญ่นี่แหละ ที่กลายเป็นจุดอ่อนของ debian เพราะผู้ใช้ทั่วไปนั้น ชอบมองที่ความเปลี่ยนแปลงแบบกระโดด คล้ายๆ กับการเปลี่ยนจาก Windows 98 เป็น XP เป็น Vista ดูมันมีความตื่นเต้นน่าจับตา แม้จะรอนานก็ดูจะไม่เป็นปัญหาอะไร การเปลี่ยนแปลงแบบต่อเนื่องแบบ debian นั้น แม้จะทำให้ได้ใช้ของใหม่ทุกวันแบบทันทีทันใด แต่ก็ไม่สร้างความตื่นเต้นอะไรมากสำหรับผู้ใช้ (แต่ถ้าใครได้อ่าน The Cathedral and the Bazaar [ฉบับแปล] จะเข้าใจ ว่าในมุมมองของชุมชนผู้ใช้-ผู้พัฒนาแบบโอเพนซอร์สแล้ว การ "release early, release often" มันให้อารมณ์ต่างจากวิธี release แบบอั้นไว้นานๆ แบบ proprietary software มากนัก) ในเมื่อสิ่งที่ผู้ใช้เพ่งเล็งคือ stable release และ debian เลือกวิธี release เมื่อพร้อมสุดๆ ถึงขนาดมีคนบอกว่า ต้องทำลายได้ด้วยวิธียิงจรวดถล่มเท่านั้น debian ถึงจะ release ได้ ก็เลยทำให้ภาพของ debian ที่ปรากฏต่อสาธารณะออกมาเป็นอย่างที่เห็น

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

ทว่า ubuntu และ debian ยังต้องพึ่งพิงอาศัยกันเหมือนน้ำกับป่า การที่จะมองจากมุมมองผู้ใช้ล้วนๆ แล้วเปิด "ศึก" ระหว่าง ubuntu-debian ขึ้นมา มันมีแต่จะสร้างภาพที่บิดเบี้ยวไปทุกที "เสียงกระแนะกระแหน" จาก debian ที่ Mk พูดถึง น่าจะเริ่มจากการตีความในมุมมองผู้ใช้หรือนักวิจารณ์ทั้งหลาย ที่ตีความคำพูดของบุคคลต่างๆ ที่พยายามออกมาอธิบายจุดยืนของ debian ในช่วงแรกๆ ไปในทาง "อิจฉา" โดยไม่มองถึงเป้าหมายที่ต่างกันของ distro ทั้งสองตามความเป็นจริง ความจริงตามหลักการแล้ว debian ซึ่งเป็นต้นน้ำให้กับ ubuntu ก็ไม่อยู่ในฐานะที่จะ "ดิ้นสุดชีวิต" เพื่อรักษาอะไรอยู่แล้ว เพราะความสำเร็จของ ubuntu ก็ควรจะถือเป็นความสำเร็จของ debian อยู่แล้ว แต่การตอกลิ่มของฝ่ายต่างๆ นั่นแหละ ที่จะเป็นชนวนให้ค่อยๆ เกิด "ศึก" ขึ้นจริงๆ

"ศึก" ที่ว่านั่น ก็ขยายผลมากขึ้น เมื่อมันกลายมาเป็นสิ่งที่เกิดขึ้นจริงในทางปฏิบัติ การที่นักพัฒนา debian คนสำคัญๆ (เช่น apt maintainer, GNOME team ฯลฯ) ถูกดึงตัวไปทำ ubuntu ในส่วนหลักแทน จนมีเวลาน้อยลงที่จะ sync ไปมาระหว่าง 2 distro ก็ทำให้งานหลายส่วนใน debian ต้องชะงักงัน ลักษณะการ "release early, release often" (ในแบบของการ upgrade ต่อเนื่อง) ที่เคยลื่นไหลก็เริ่มฝืด (แต่ฝืดแค่ไหน ubuntu ก็ยังได้อาศัยในการ sync อยู่ เรียกว่ารีดไปแบบเต็มพิกัด) ประกอบกับเมื่อ debian มีปัญหาภายใน บางคนก็ walk out ไปร่วมกับ ubuntu เสียดื้อๆ จึงทำให้เกิดความขุ่นเคืองต่อ ubuntu สะสม แต่หลายคนก็รักษาตบะไว้ได้ แล้วทำงานให้หนักขึ้นด้วยสปิริต โดยยังมอง ubuntu เป็นมิตร และเมินเสียงยุแยงจากส่วนต่างๆ เสีย ขณะเดียวกันก็มีคนเลือดใหม่เข้ามาทดแทนในส่วนที่ซบเซา

ความรู้สึกผมโดยรวมต่อเรื่องนี้ ก็ไม่ได้ต่างจากสมัยที่ทำ TLE ในแบบที่มอง TLE เป็น buffer แต่เน้นการ check-in เข้าที่ต้นน้ำเท่าไร พองานของตัวเองที่ต้นน้ำเริ่มมีผลใน distro อื่น เช่น Mandrake แล้วมีคนมาด่า ว่าภาษาไทยใน TLE สู้ Mandrake ไม่ได้ ก็ทั้งขบขันที่งานของตัวเองต้องย้อนมาแข่งกับตัวเอง ปนกับอึดอัดที่ไม่รู้จะพูดยังไงไม่ให้ user และนักวิจารณ์มองว่า "อิจฉา" ก็คงทำนองเดียวกันน่ะแหละ สิ่งนั้นก็มีส่วนทำให้ผมต้องมาเน้นความสำคัญของ "ต้นน้ำ" มากขึ้นอย่างที่เป็นอยู่ ให้ผู้คนคลายความยึดมั่นถือมั่นกับหีบห่อที่ตีตราต่างยี่ห้อลงเสีย

ผมชอบโฆษณาชายี่ห้อหนึ่งนะ ที่มีฝาแฝดที่พิถีพิถันกับการดื่มน้ำ ชวนเพื่อนขึ้นไปดื่มน้ำที่ "ต้นน้ำ" ที่นั่น น้ำสะอาดน่ากินกว่าเยอะ ตราบใดที่ debian ยังคงเป็นต้นน้ำให้กับ ubuntu อยู่ ผมก็ย่อมเลือกทำงานกับ debian เป็นหลัก ซึ่งจะส่งผลไปถึง ubuntu ด้วย แต่ถึงอย่างไร ก็ยังมี "ต้นน้ำ" จริงๆ ที่เป็นแหล่งให้กับทุก distro ซึ่งสำคัญกว่า และยังคงเป็นเป้าหมายหลัก

Iceweasel and Ubuntu

peorth, ดูจะเขียนกำกวมอยู่นะ เรื่อง pango บน iceweasel ที่ว่า render ภาษาไทยเพี้ยน แต่ไม่ได้บอกว่าเพี้ยนยังไง เดี๋ยวชาวบ้านเข้าใจผิดหมด

pango นั้น ช่วยให้ iceweasel แสดงภาษาไทยได้โดยวรรณยุกต์ไม่ลอย แต่ยังมีปัญหากับเว็บที่ใช้ character spacing อยู่ ซึ่งรวมถึงเว็บที่ใช้ justified text ด้วย เรื่องของเรื่องก็คือ บังเอิญว่าบางเว็บของ peorth เขาใช้ character spacing เลยเจอปัญหาหนัก แต่สำหรับเว็บที่ไม่ได้ใช้ ก็ไม่มีปัญหาอะไร

ถ้าต้องเลือกระหว่างใช้ pango แล้ววรรณยุกต์ไม่ลอย แต่ character spacing เพี้ยน กับไม่ใช้ pango แล้วยอมให้วรรณยุกต์ลอย แต่ character spacing ไม่เพี้ยน ว่ากันตาม usability ก็น่าจะเลือกปิด pango นั่นแหละ แต่เนื่องจากเว็บส่วนใหญ่ที่ผมอ่าน ไม่ค่อยได้ใช้ justified text กัน ก็เลยเลือกความสบายตาจากวรรณยุกต์ที่ไม่ลอย แต่ก็ทำให้เจอปัญหากับเว็บที่ใช้ justified text เป็นบางโอกาสเหมือนกัน

แต่ปัญหา pango กับ character spacing นี่ ก็รอเขาแก้อยู่นานละ เห็น Owen Taylor เสนอไว้ ตั้งหลายปีมาแล้ว แต่หลังๆ เห็นแกเงียบไป โดย Behdad Esfahbod เข้ามาแอคทีฟแทน ก็ต้องรอลุ้นกันต่อไป

ส่วนเรื่องที่ firefox® กับ iceweasel ชนกันนั้น ไม่ได้แปลกใจเลย เพราะตอนที่ เตรียม source นั้น เตรียมไว้สำหรับ debian และที่ไปหาคน build i386 deb ในห้องแช็ต ก็ขอ deb สำหรับ debian sid ไม่ใช่สำหรับ ubuntu (แต่ที่ได้ deb สำหรับ edgy แทนนั้น คงมาจากการสื่อสารที่ผิดพลาด แต่สุดท้ายผมก็ได้ build เองใน i386 chroot ละ) ซึ่งใน debian นั้น ออกแบบให้ iceweasel มาแทน firefox® โดยเฉพาะ แพกเกจ firefox ที่ upgrade จึงเป็นแพกเกจเปล่าที่ depends on iceweasel เพื่อให้ apt ไปดึง iceweasel มาลงแทนเท่านั้น ไม่เหลืออะไรให้ conflict อีก ซึ่งต่างกับ ubuntu ที่ยังใช้ firefox® แบบเต็มๆ เพราะไม่ได้คิดจะใช้ iceweasel มาแต่ต้น

สำหรับ TLE ที่แม้จะใช้ ubuntu แต่ก็ดูเหมือนจะใช้ iceweasel จึงเข้าใจว่าคงไม่มีปัญหาเรื่อง conflict ที่ว่าเช่นกัน แต่ถ้าจะให้ลง iceweasel ใน ubuntu ต้นฉบับที่ยังมี firefox® อยู่ ก็ต้องกำหนดให้ iceweasel Conflicts: firefox ด้วย จึงจะราบรื่น

แต่ทั้งนี้ทั้งนั้น ก็ไม่ได้คิดจะเตรียม iceweasel เพื่อใช้กับ ubuntu อยู่แล้วนะครับ จะทำยังไงต่อไปคงขึ้นอยู่กับคนที่ support ubuntu ละ

Translation Must Go On

กลับมาที่งานแปล GNOME 2.18 ต่อ.. ระหว่างที่เข้ากรุงแล้วไม่ได้เช็กเมล ก็ปรากฏว่า มีการประกาศ Module decisions for GNOME 2.18 ไปแล้ว โดยผลก็คือ:

• แพกเกจที่ถอนตัว:
  • GnomeScan
  • tracker
  • monodevelop
• แพกเกจที่ได้เข้า:
  • devtools suite
  • seahorse
  • nm-applet
  • devhelp
  • glade3
• แพกเกจที่ไม่ได้เข้า:
  • gnome-main-menu
  • anjuta

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

ช่วงที่ผ่านมา ได้คำแปล orca จากพี่ปลาที่เนคเทค และคำแปล gtk+-properties (นิดหน่อย) จากนิวตรอนมาเสริม บวกกับที่ผมแปล seahorse รวมทั้งไล่แปลแพกเกจเก่าต่างๆ ประกอบกับมีแพกเกจที่ถูกตัดออก ทำให้เปอร์เซ็นต์แปลของไทยตอนนี้กลับมาอยู่เหนือ 80% อีกครั้ง โดยล่าสุดอยู่ที่ 83.64% แซงขึ้นมาหลายอันดับอยู่

ยังต้องแปลต่อไป กับเวลาหนึ่งเดือนที่เหลือนี้ (ตาม กำหนดการ GNOME 2.18.0 จะ tarballs due 12 มีนานี้) ที่ผ่านมาก็ออก 2.17.90 (2.18.0 Beta 1) ไปแล้ว และจะออก Beta 2 วาเลนไทน์นี้ ใครที่ใช้ GARNOME อยู่ หรือตาม Ubuntu feisty อยู่ ก็ช่วยกันตรวจสอบคำแปลกันได้เช่นกันครับ โดยแจ้งเข้ามาที่ ทีมแปล อ้อ.. ทีมไทยพยายาม หลีกเลี่ยงการแปลผ่าน launchpad/rosetta เพื่อลดความซ้ำซ้อนนะครับ กรุณาติดต่อ mailing list ทีมแปล แทน

Notes on the new Planet

บันทึกช้าไปไหมนี่ เกี่ยวกับ Planet TLWG โฉมใหม่ที่แอบทำไปเมื่อเดือนที่แล้ว หลังกลับจากเซ็ตเครื่องและพบ Debian Developer ที่กรุงเทพฯ

คราวนี้ใช้ planet จาก debian etch แทนตัวที่ลงจาก source ที่คุณพูลลาภเคยทำไว้ในรุ่นก่อน หลังจากที่เขามีให้แล้วใน debian ปรากฏว่า planet รุ่น 2 นี้ มีการปรับปรุงการ parse feed มากพอควร ทำให้ patch ต่างๆ ที่เคยทำไป ไม่จำเป็นต้องใช้อีกแล้ว ยกเว้นการใช้ localtime แทน UTC เท่านั้น

และเพื่อใช้กับเว็บ LTN รุ่นที่ 3 เลยตกแต่งหน้าตา planet เสียใหม่ แต่ยังไม่มีเวลาพอจะเปลี่ยนโครงสร้างอะไรมากมาย ก็ปรับแต่ง CSS stylesheet แล้วก็เปลี่ยนแถบหัวเรื่อง โดยอาศัยภาพที่เป็น public domain จาก Wikipedia:

ก่อนทำ:

หลังทำ:

รูปภาพโลกที่มีระดับชั้นบรรยากาศ เอามาจากหน้า Earth ส่วนรูปเพนกวินจักรพรรดิ์ เอามาจากหน้า Penguin (รูปนี้เคยได้รับการคัดเลือกให้เป็น Picture of the Day มาแล้วถึง 3 ครั้ง ก็สมควรอยู่นะ ตอนหารูปก็รู้สึกสะดุดตารูปนี้ที่สุด) แล้วเอามาแต่งด้วย gimp ก่อนเอามาแปะในแถบพาดหัว ส่วนข้อความ "Planet TLWG" นั้น ใช้ฟอนต์ URW Palladio L ซึ่งอยู่ในแพกเกจ gsfonts ใช้ license แบบ GPL

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

The Power of Unix Design

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

แต่สิ่งที่อยากสรุปเสริมจากงานทั้งหมดครั้งนี้ ก็คือว่า มันเป็นตัวอย่างหนึ่งของพลังของ Unix Design ในสถานการณ์ที่ต้องทำอะไรอัตโนมัติอย่างนี้ GUI ที่สวยหรูไม่ได้ช่วยอะไรเลย แต่ command line option ที่ยืดหยุ่น ประกอบกับเครื่องมืออื่นๆ ที่ทำงานร่วมกันเป็นอย่างดีต่างหาก ที่ช่วยให้งานเสร็จได้โดยง่าย

ขอยกคำพูดบางตอนของ ESR ใน The Art of Unix Programming:

Many operating systems touted as more ‘modern’ or ‘user friendly’ than Unix achieve their surface glossiness by locking users and developers into one interface policy, and offer an application-programming interface that for all its elaborateness is rather narrow and rigid. On such systems, tasks the designers have anticipated are very easy — but tasks they have not anticipated are often impossible or at best extremely painful.

Unix, on the other hand, has flexibility in depth. The many ways Unix provides to glue together programs mean that components of its basic toolkit can be combined to produce useful effects that the designers of the individual toolkit parts never anticipated.

ลองแปลเสียหน่อย:

ระบบปฏิบัติการหลายตัวที่อวดตัวว่า ‘ทันสมัย’ หรือ ‘เป็นมิตรกับผู้ใช้’ กว่ายูนิกซ์ ได้ประสบความสำเร็จเรื่องความเงางามอย่างผิวเผิน ด้วยการตีกรอบผู้ใช้และนักพัฒนาด้วยนโยบายอินเทอร์เฟซเดียว และอินเทอร์เฟซสำหรับพัฒนาโปรแกรม (API) ที่ไล่เรียงรายละเอียดถี่ยิบแต่ค่อนข้างแคบและตายตัว ในระบบเหล่านั้น งานที่ผู้ออกแบบได้คาดการณ์ล่วงหน้าไว้จะทำได้ง่ายมาก - แต่สำหรับงานที่ผู้ออกแบบไม่ได้คาดการณ์ไว้แล้ว มักจะเป็นไปไม่ได้เลย หรืออย่างดีที่สุดก็ทำได้ยากเหลือแสน

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

สิ่งที่ผมชอบใน GNOME และอยากให้มีต่อไป ก็คือเรื่องการใส่ใจในดีไซน์แบบ Unix นี่แหละ อย่าง totem ก็เห็นตัวอย่างไปแล้ว ว่าถ้าออกแบบ command line ให้ดีพอ ก็สามารถใช้เครื่องมืออื่นอย่าง cron หรือ ssh สั่งการในแบบที่ต้องการ โดยผู้ออกแบบ totem ไม่จำเป็นต้องคิดล่วงหน้าไปไกล ว่าจะมีใครใช้ totem เล่นหนังแบบตั้งเวลาหรือเปล่า จะมีการควบคุมผ่านเครือข่ายหรือเปล่า หรือการใช้งานแบบอื่นที่ยังไม่เคยปรากฏ

ในส่วนโครงสร้างพื้นฐาน GNOME ใช้ gconf ในการควบคุมค่าตั้งของโปรแกรมต่างๆ ซึ่งจะมี gconfd เป็น daemon คอยกระจายการเปลี่ยนค่าตั้งแบบทันทีทันใดไปยังโปรแกรมเป้าหมาย พร้อมทั้งมี command line (gconftool) สำหรับติดต่อกับ gconfd ด้วย ทำให้การสั่งการเดสก์ท็อปแบบอัตโนมัติทำได้ยืดหยุ่นมาก เช่น เคยมีคนทำ hack สำหรับเปลี่ยนพื้นหลังด้วยภาพที่คำนวณจากโปรแกรม xplanet แสดงส่วนมืดสว่างของโลกแบบ real-time หรือถ้าจะควบคุม config ของโปรแกรมต่างๆ ผ่าน crontab ก็ย่อมทำได้

นอกจากนี้ ยังรู้มาว่า AbiWord สามารถสั่งแบบ command line ได้ด้วย ช่วยให้งานบางอย่าง เช่น การแปลงฟอร์แมตหรือแก้ไขเอกสารจำนวนมาก ทำได้ผ่าน shell script หรือ make rules (คล้ายกับที่ระบบ build ของ thaifonts-scalable ใช้กับ fontforge) หรือหากใครคิดเชื่อมโยงกับโปรแกรมอื่น ก็อาจใช้ shell script สั่งเรียงลำดับงานกับโปรแกรมอื่นได้ตามความต้องการ

หากสำรวจดีๆ ก็จะเห็นว่าโปรแกรมใน GNOME หลายตัวมี command line option เยอะแยะ เรื่องพวกนี้ ไม่ได้มีไว้ให้ปวดหัวกันนะครับ แต่ถ้าได้เจอสถานการณ์บางอย่าง คุณจะถามหาตัวเลือก command line จาก manpage ราวกับควานหาเมนูใน GUI เชียวแหละ และคุณจะรู้สึกขอบคุณ ที่แม้โปรแกรมเหล่านี้จะเป็น GUI แต่ก็ยังใส่ใจคุณพอที่จะทำ command line interface เจ๋งๆ ให้

iceweasel-libthai bug

เมื่อวาน MrChoke มาโวยว่า iceweasel ที่ patch libthai มีปัญหาเรื่องตัวสี่เหลี่ยมกับ NL ซึ่งผมไม่เคยเจอ เพราะใช้แต่ epiphany เป็นหลัก ก็เลยจัดการ build iceweasel-libthai 2.0.0.1 เพื่อทดสอบบน debian (ความจริงรอ Prach ทำให้อยู่ แต่ต้องรอเขาเซ็ตเครื่องใหม่ก่อน หลังจากกลับไปอยู่โคราช)

build เสร็จก็ไม่พบอาการที่ว่าบน debian เอ๊ะ ยังไงกัน สรุปว่าเป็นแต่กับ ubuntu รึนี่ ไม่รู้ละ ไหนๆ ก็ build amd64 deb เสร็จแล้ว ก็เข้าห้อง #tlwg ไปหาคนช่วย build i386 deb สำหรับ debian ซึ่ง peorth ก็อาสา build ให้ thanks หลายๆ

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

ค่ำๆ แปลเสร็จเลยกลับมาลุย อาการก็คือ white space ใน HTML ที่อยู่หลังข้อความจะถูก render ตรงๆ แทนที่จะถูกตีความเป็น delimiter ของข้อความตามไวยากรณ์ HTML เลยตั้งสมมุติฐานว่าคงอยู่ที่จุดตัดคำที่ส่งมาตั้งแต่ libthai พอไล่ไปไล่มาก็พบว่าใช่จริงๆ ก็จัดการแก้ซะ แล้ว commit เข้า CVS

อะ มีเวลาเหลืออีก เลยคิดว่าควร build deb ใหม่ให้ชาวบ้านใช้เสีย เพราะเห็นบ่นกันอยู่หลายแห่งในเว็บ ปล่อยให้เขาเดือดร้อนกันต่อไปคงไม่งาม เลยได้ libthai 0.1.7-5 ที่แก้ปัญหานี้แล้ว อยู่ที่ LTN APT นะครับ พร้อมกับ iceweasel-libthai 2.0.0.1+dfsg-2thai1 สำหรับ amd64 (ส่วน i386 รอ deb จาก peorth) และคาดว่าปัญหา xulrunner ที่คุณ cwt เคยพบ ก็อาจถูกแก้พร้อมกันด้วย (ช่วยยืนยันด้วยครับ) ..ทั้งหมดนี้สำหรับ debian นะครับ ส่วนสำหรับ ubuntu คาดว่าทีม TLE คงรอทำให้อยู่แล้ว

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

Scheduled Video Broadcast

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

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

ทีแรก ก็นึกถึง solution แบบ video streaming ไว้ก่อนเลย เพราะจะสามารถใช้ LAN ของโรงเรียนกระจายสัญญาณไปที่จุดต่างๆ ได้เลย แต่ด้วยข้อกำหนดที่ต้องการแสดงสื่ออย่างอื่นนอกจากวีดิทัศน์ได้ด้วย เช่น slide show จึงต้องเปลี่ยนมาเป็นระบบเล่นออกจอเดียว แล้วใช้วิธีพ่วงสายทีวีเอา

ซึ่งก็ปรากฏว่าง่ายลงเยอะ โดยปัญหาถูกลดลงเหลือแค่การตั้งเวลาเล่นสื่อเท่านั้น ทำให้สามารถใช้โปรแกรมได้หลากหลายขึ้น จากเดิมที่คิดว่าคง VLC แน่ๆ ก็สามารถใช้เครื่องมืออย่าง Totem หรือ xine ได้ (Mplayer นั้น ยังไม่เคยใช้) แต่ปรากฏว่าไม่มีเวลาพอจะสำรวจความสามารถเรื่องการตั้งเวลาของ xine ได้แค่สำรวจ vlc และ totem เท่านั้น

vlc นั้น มี VLM ที่สามารถกำหนด schedule ได้ จึงสามารถตั้งโปรแกรมสถานีได้ ว่าจะเล่นอะไรเวลาไหน แต่ข้อจำกัดคือ ยังขาดความยืดหยุ่นในการควบคุมหากต้องการภาพออกจออย่างต่อเนื่อง โดยไม่เผยให้เห็นเดสก์ท็อปข้างหลัง เพราะเท่าที่ดูคำสั่งแล้ว ปัญหาใหญ่คือ VLM ไม่สามารถแทรกการควบคุมหลังจากเล่นสื่อที่เล่นรอบเดียวจบแล้วได้ และไม่สามารถปิดสื่อที่เล่นแบบ repeat ได้ด้วย เพราะเมื่อปิดแล้วก็จะเริ่มเล่นใหม่เสมอ หากจะทำได้ ก็แค่สั่ง pause หรือ play เท่านั้น

ผลก็คือ ถ้าจะโปรแกรมให้มีสื่อคั่นเวลาในช่วงต่อระหว่างโปรแกรม (เพื่อไม่ให้เผยเดสก์ท็อปข้างหลัง) จะทำได้ยาก เพราะจะให้ pause สื่อคั่นเวลาที่ repeat แล้วเล่นสื่อตามโปรแกรมรอบเดียว จบแล้ว play สื่อคั่นเวลาต่อ ก็ทำไม่ได้

นอกจากนี้ ยังมีปัญหาเรื่องการเหลื่อมของโปรแกรม โดยหากถึงเวลาเล่นสื่อตามกำหนด แล้วยังมีสื่ออื่นเล่นอยู่ vlc ก็จะไม่ยอมเล่นสื่อตามกำหนดนั้นเสียเฉยๆ โดยมีข้อความ debug บอกว่า resource ไม่ว่าง

อาจมีวิธีปรับแต่งได้มากกว่านี้ แต่ด้วยเวลาที่จำกัด จึงไม่สามารถสำรวจมากกว่านี้ได้ และเมื่อมาดู totem กลับพบวิธีควบคุมที่ง่ายกว่า

แทนที่จะใช้ telnet interface เหมือน vlc (ซึ่งความจริงคงสะดวกสำหรับการใช้งานในเครือข่าย) totem สามารถควบคุมผ่าน command line ได้ โดยสามารถสั่ง replace สื่อที่กำลังเล่นในหน้าต่างเดิมได้เลย โดยใช้ตัวเลือก --replace filename|URI (ใส่หลายสื่อได้)

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

ส่วนเรื่องการตั้งเวลาเล่น totem ยังไม่มีความสามารถนี้เหมือน vlc แต่ก็ไม่ใช่ปัญหา เพราะสามารถตั้ง crontab สั่ง replace play list ของ totem ตามกำหนดเวลาได้

หมดเวลาสำรวจ.. ยังไม่ได้ดูตัวอื่นต่อเลย ก็คงลงเอยที่ totem นี่แหละ เมื่อตั้งให้เปิด totem แบบ fullscren โดยอัตโนมัติในแบบ kiosk แล้ว ก็แค่รอ cron สั่งเล่น play list ตามกำหนดเวลาเท่านั้นเอง ข้อเสียเปรียบหลักๆ ของ totem สำหรับงานนี้ ก็คงอยู่ที่เรื่อง format ที่เล่นได้ ยังไม่หลากหลายเท่า vlc แต่ก็พยายามถูไถ ด้วยการแปลง format ได้

คำถามที่อาจเกิดขึ้นคือ แล้วจะใช้ crontab ควบคุม vlc แบบที่ควบคุม totem ไม่ได้หรือ? คำตอบคือ vlc เผยเดสก์ท็อปด้านหลังง่ายเกินไป พอเล่นสื่อที่ไม่มีภาพ ก็จะหดหน้าต่างปิดส่วนแสดงภาพไปเลย หรือถ้าเล่นวีดิทัศน์จบแล้ว ก็หดหน้าต่างลงทันทีเหมือนกัน เมื่อเทียบกับวิธี replace play list ของ totem แล้ว ดู totem จะควบคุมได้ตามความต้องการมากกว่า