โปรแกรมอ่านเมลเป็นโปรแกรมที่หาถูกใจได้ยากที่สุด บนลินุกซ์นี่เคยลองโปรแกรมอ่านเมลมาเป็นสิบตัว ตั้งแต่ pine, mutt, .. สุดท้ายก็มาลงที่ sylpheed ทำงานเร็ว กินหน่วยความจำก็น้อย ภาษาไทย ok บันทึกเป็น MH export เป็น mbox ได้ ใช้ GTK+ 1.x .. ระยะหลังๆ พยายามปรับเข้า GTK 2.x / GNOME 2.x เลยได้ตามหาโปรแกรมอ่านเมลอีกรอบ ..

1. Balsa เป็นความหวังแรก เพราะค่อนข้าง lightweight แต่มันมีปัญหากับ SSL/TLS .. ลงทุนเอา fetchmail ไปโหลดเมลมาให้ Balsa อ่านจาก local mbox ก็ยังติดจุกจิกหลายเรื่อง ใช้อยู่ประมาณวันนึงก็ทนไม่ไหว ลบทิ้งไป .. balsa is broke :(
2. Mozilla Mail … โอเคแหละ เสียที่กินหน่วยความจำเยอะ ตามสไตล์ Mozilla .. ใช้แล้วก็ยังไม่ถูกใจอยู่ดี (เรื่องมาก :P)
3. Thunderbird .. โดยรวม ดูดี น่าใช้ ฟึเจอร์ครบเท่าที่ต้องการ .. พอ ps aux ดู VSZ/RSS แล้วแทบจะ rpm -e ซะเดี๋ยวนั้น .. โปรแกรมอ่านเมลไรฟะ virtual size ร้อยกว่าเม็ก .. บ้าป่าว .. นี่ขนาดเพิ่งใช้ มีเมลไม่ถึงห้าฉบับนะเนี่ยะ ..

สุดท้าย ก็มาใช้ Evolution จนได้ .. กินหน่วยความจำพอสมควร แต่ไม่บ้าเลือดเหมือน Tbird .. เวอร์ชัน 2.0.1 นี่ถอดชนวนระเบิดไปหลายจุด เท่าที่ใช้มาก็ยังไม่มีอาการแครชอย่างที่เคยเจอกับ 1.5.x/2.0.0 … แสดงผลภาษาไทยก็ ok … อืม คงลองใช้ดูสักวันสองวัน …

ดราฟต์โลโก้ ‘โลมา’ เป็น svg จากภาพบิตแม็พ 48×48 จุด .. ลอกอยู่พักใหญ่ก็เลิก วาดใหม่หมดเลยดีกว่า โดยให้ออกมาคล้ายๆ โลโก้เดิม จะได้ไม่ผิดสังเกตมาก .. ผลลัพธ์ออกมาเป็นแบบนี้:

ดูแล้วมั่วๆ พอสมควร แต่พอย่อเป็นไอคอนแล้วก็คงไม่เห็นความมั่วหรอกน่า :P

PS: ‘โลมา’ ไม่ใช่ ‘ปลาโลมา’.. โลโก้วาดบน Inkscape 0.39 / Aowthai

สัปดาห์ที่แล้ว MrChoke แจ้งมาว่า ทะเลจะใช้ GCC 3.4 เป็นคอมไพเลอร์หลัก และใช้ GCC 3.3 เป็น compat .. แปลว่า ต้อง rebuild แพ็กเกจทั้งหมด (T_T) .. นั่งปั่น เสาร์-อาทิตย์ สองวันเสร็จ ทั้งหมด 319 RPMS / 199 SRPMS .. เข้า people เรียบร้อยแล้ว :)

ยังเหลือ extras ที่มีจำนวนพอๆ กัน .. แต่อันนี้ทยอยทำไปเรื่อยๆ ได้

สั่ง apt-get update/upgrade จาก NECTEC ปรากฏว่ารีบูตแล้วค้าง .. ไม่มี /dev/console ! .. เลยบูตแผ่นทะเล สั่ง linux rescue เข้าไป MAKEDEV .. make อะไรได้เอาหมดเลย ตอนนี้ /dev เกือบๆ หมื่นไฟล์ (- -‘) .. ก็ยังดีกว่าใช้งานไม่ได้แหละ .. เฮ่อ

แก้โค้ด atom feed นิดหน่อย ตอนนี้โปรแกรม feed reader อย่าง sage หรือ thunderbird ควรจะรับ feed จาก kitty.in.th ได้แล้ว :)

วันนี้แวะเอาแผ่นซีดีไปฝากพี่เทพที่บ้าน นั่งคุยกันสารพัดเรื่อง นานทีเดียว .. :)

เรื่องนึงที่คุยกันคือเรื่อง swap ในลินุกซ์ .. มีกรณีแปลกๆ ที่่ผ่านตา คือ มีคนเอาหน่วยความจำมาทำเป็น RAM disk แล้วเอามาใช้เป็น swap บนเคอร์เนล 2.4 .. อ่านเรื่องเต็มๆ ได้ที่ http://kerneltrap.org/node/view/3660 .. คอมเมนต์ยาวมาก ผู้เขียนบทความพยายามอธิบายว่าการใช้หน่วยความจำมาทำเป็น swap ดีกว่า การ swap ลงดิสก์ (ซึ่งก็แหงๆ ล่ะ) .. และการทดสอบโดยผู้เขียนเองได้ผลว่าใช้หน่วยความจำทำ swap ดีกว่า ไม่มี swap เลย .. อันนี้ดูไม่น่าเป็นไปได้ แต่ก็ไม่มีอะไรชี้ชัด ตามคนต่างคอมเมนต์ตามสมมติฐานซะมากกว่า .. สรุป .. ไม่มีคำตอบ .. ลองกันเอาเอง

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

ขนาดของ swap เดิมเชื่อกันว่าควรจะตั้งไว้ประมาณ 2 x หน่วยความจำ .. ที่อ่านๆ เจอ เรื่องนี้มีที่มาอยู่หลายทาง หนึ่งในนั้นคือ มาจากขนาด swap ของระบบยูนิกซ์สมัยแรกๆ .. และอีกหนึ่งมาจากเหตุที่เคอร์เนลรุ่นแรกๆ ทำงานได้ไม่ดี ถ้าขนาด swap เล็กเกินไป .. ปัจจุบัน swap ไม่จำเป็นต้องเป็นสองเท่าของหน่วยความจำ สำหรับเดส์กท็อป หน่วยความจำ 256 – 512 MB ตั้ง swap ไว้ซัก 512 MB ก็น่าจะเกินพอแล้ว มากกว่านี้ก็เปลืองเนื้อที่เปล่าๆ ยิ่งถ้าหน่วยความจำเยอะกว่านี้ swap ก็จำเป็นน้อยลง .. อีกอย่างนึงคือ ขนาดของ swap มีลิมิตที่ kswapd ซึ่งตอนนี้ ยังทำงานเป็น 32-bit .. ขนาด swap สูงสุดอยู่ที่ 2 GB/โพรเซส .. หากจะตั้ง swap เกิน 2 GB ก็ได้ แต่ kswapd จะอ้างอิงได้แค่ 2 GB แรก

สำหรับเคอร์เนล 2.6 มีการเปลี่ยนแปลง VM ไปจาก 2.4 ค่อนข้างมาก สามารถปรับแต่งการทำงานของ VM ให้เหมาะกับภาระงานของเครื่องนั้นๆ ได้ระดับนึง กระนั้นก็ยังไม่ถือว่าสมบูรณ์แบบ (เช่นเดียวกับโอเอสอื่นๆ ที่สนับสนุน VM/swapping ทุกๆ ตัว) .. ระยะหลังเลยเริ่มมีเสียงว่า เคอร์เนลอาจจะต้องทำ VM ไว้ใช้สำหรับงานต่างๆ กัน เช่น การใช้เป็นเดสก์ท็อป ทั่วไปแล้วมีหน่วยความจำ 128 – 512 MB การใช้งานแอพพลิเคชันหลากหลาย เปลี่ยนแปลงตลอดเวลา และต้องการการตอบสนองที่ดี – สลับหน้าจอแอพพลิเคชันได้เร็วขึ้น 1 วินาทีมีความหมายมากกว่าคอมไพล์เคอร์เนลได้เร็วขึ้น 1 นาที – VM สำหรับเดสก์ท็อปอาจจะต้องทำงานแบบนึง ในขณะที่ เซิร์ฟเวอร์ ตามทฤษฎีมีหน่วยความจำที่มากกว่า มีแอพพลิเคชันที่อยู่ในหน่วยความจำค่อนข้างแน่นอน ไม่ค่อยมีการเปลี่ยนแปลง VM ก็อาจจะต้องทำงานอีกแบบ ..

จะว่าไป .. หลังๆ มีแพตช์/kernel tree ที่ปรับแต่งสำหรับเดสก์ท็อปหรือเซิร์ฟเวอร์โดยเฉพาะอยู่เหมือนกัน .. :)

เมื่อไม่นานมานี้ ลินุสได้ตัดสินใจถอดไดรเวอร์ Philips-based USB webcam ออกจากลินุกซ์ เคอร์เนลเวอร์ชันถัดไปอาจจะไม่สนับสนุนเว็บแคมที่ใช้ชิปของ Philips แล้ว … เรื่องนี้ส่งผลกระทบต่อผู้ใช้เต็มๆ เลยกลายเป็นเรื่องที่วิพากษ์วิจารณ์กันเยอะทีเดียว

เรื่องของเรื่องก็คือไดรเวอร์ตัวนี้มันไม่โอเพ่นซอร์ส หรืออาจจะเรียกว่ากึ่งโอเพ่นซอร์ส .. ไดรเวอร์นี้ประกอบด้วยสองส่วนคือ PWCX ที่เป็นโค้ดของไดรเวอร์ พัฒนาโดย Nemosoft Unv. โค้ดส่วนนี้ไม่ได้โอเพ่นซอร์สเพราะติด NDA (Non-Disclosure Agreement) ทาง Nemosoft จึงจำต้องเผยแพร่เป็นไบนารีเพียงอย่างเดียว เมื่อเปิดเผยไม่ได้ PWCX จึงไม่สามารถอยู่ในเคอร์เนลได้ .. เพื่อแก้ปัญหาเรื่องนี้จึงมีโค้ดส่วน PWC ทำหน้าที่เป็นจุดเชื่อม หรือ ‘hook’ ให้กับ PWCX โดย PWC เผยแพร่ด้วย GPL และอยู่ในเคอร์เนลของลินุกซ์ .. โค้ด PWC เป็นไดรเวอร์ทำงานด้วยตัวมันเองได้ แต่จำกัดมากๆ และในความเป็นจริง PWC ไม่ได้เขียนเป็นไดรเวอร์ แต่ใช้เพื่อเป็น hook โดยเฉพาะ .. การทำ hook สำหรับไดรเวอร์แบบไบนารีในเคอร์เนลถือเป็นเรื่องที่ยอมรับไม่ได้ เพราะทำให้เคอร์เนลไม่ ‘สะอาด’ จริง .. เมื่อเป็นเช่นนั้น Greg Kroah (USB maintainer) จึงตัดโค้ดส่วนของ hook ใน PWC ออก (เน้น: ตัดโค้ดของ hook .. ไม่ใช่ตัด PWC) ทำให้ต่อไป PWC จะไม่สามารถโหลด PWCX มาใช้งานได้ .. Nemosoft เห็นเช่นนั้นก็มีท่าทีที่ไม่พอใจเท่าไหร่นัก จึงตัดสินใจหยุดพัฒนาไดรเวอร์นี้ทั้ง PWC/PWCX และขอให้ถอด PWC ออกจากเคอร์เนล .. และลินุสก็ทำตามประสงค์ของ Nemosoft

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

1. PWC เรียกว่าเป็น hook-only for binary-only driver ซึ่งทำให้เคอร์เนลไม่เสรี/โอเพน
2. ไม่มีคนรับดูแล PWC ต่อจาก Nemosoft และ
3. ลินุสถือว่า Nemosoft เป็นเจ้าของโค้ด PWC/PWCX เมื่อเจ้าของไม่ต้องการให้โค้ดอยู่ในเคอร์เนล ก็ถือว่าเป็นเรื่องใหญ่และควรจะให้เกียรติทำตามความต้องการ ถึงแม้ว่าในความเป็นจริงแล้วไม่มีใครเป็นเจ้าของโค้ดนี้ตั้งแต่แปะคำว่า GPL ..

เหตุผลที่ลินุสเน้นย้ำที่สุดคือข้อ 3 นี่แหละ ..

ใครถูกใครผิดก็ไม่รู้เหมือนกัน สำหรับผม เรื่องโอเพนซอร์สมีความสำคัญเหนือกว่าเรื่องเอาใจผู้ใช้เสมอ ไม่ว่าน้ำหนักผู้ใช้จะกดดันขนาดไหน แต่ถ้าทำให้โอเพนซอร์สไม่สะอาดเมื่อไหร่ คำว่า ‘โอเพน’ หรือ ‘ฟรี’ (as in free speech) จะไม่มีความหมายอีกเลย หากหลักการนี้ล้ม ปัญหาจะตามมาหลังจากนั้นอีกเยอะมาก ไม่เพียงเรื่องแนวคิดของโอเพน/ฟรีจะเสียไป แต่ในแง่เทคนิคก็จะเสียไปด้วย การที่มันโอเพน/ฟรีทำให้ลินุกซ์ก้าวไปได้เร็วและมั่นคง เพราะทุกคนเห็นซอร์ส ทุกคนสามารถช่วยกันแก้ไข ทุกคนสามารถช่วยปรับปรุงให้มันดีขึ้นได้ การปกปิดซอร์สทำให้ไม่สามารถคงสภาพการทำงานแบบนี้ได้อีก เสถียรภาพ และความปลอดภัยย่อมลดน้อยลง หากเกิดขึ้นกับเคอร์เนลก็คงไม่ใช่เรื่องดี

ทางออกสำหรับเรื่องนี้ ให้สวยที่สุดคือพัฒนาไดรเวอร์ที่เป็นโอเพนซอร์ส ถ้าทำไม่ได้จริงๆ ก็ย้ายส่วนไบนารีไปอยู่นอกเคอร์เนล หรือทำไดรเวอร์โมดูลที่ไม่ต้องใช้ hook ในเคอร์เนล ..

.. สุดท้ายจะออกมายังไง คงต้องติดตามดูกันต่อไป

เมื่อวาน blog เรื่องเคอร์เนลแพตช์ของ mm และ ck ไปแล้ว ยังมีแพตช์เคอร์เนลอีกหลายตัว แต่ละตัวก็ maintain tree ของตัวเอง มีจุดประสงค์ในการใช้ต่างๆ กันไป สรุปมาให้อ่านกัน:

• aa tree ของ Andrea Arcangeli เน้นเรื่อง VM เป็นหลัก .. aa tree merge เข้าเคอร์เนลตั้งแต่ 2.4.10 .. VM ของเคอร์เนล 2.6 ก็มีพื้นฐานมาจาก aa tree
• ac tree ของ Alan Cox .. Alan เป็น kernel maintainer ตั้งแต่ปลาย 2.0 2.2 เลยมาถึง 2.4 ช่วงต้นๆ ทุกคนยกย่องให้เป็นมือขวาของ Linus .. หลังวางมือ Alan ก็ยังมีส่วนช่วยงานเคอร์เนลอยู่อย่างต่อเนื่อง โดย maintain ac tree ที่มีฟีเจอร์ใหม่ๆ ที่ไม่อยู่ในวานิลลา .. ac tree ยังนับเป็นการทดสอบ bugfix และฟีเจอร์ ก่อนจะส่งให้ Marcello Tosatti (2.4 kernel maintainer ต่อจาก Alan) อีกทีด้วย .. ac patch หายร่วมปีแล้ว เพราะ Alan หยุดงานเคอร์เนลชั่วคราวไปเรียนต่อด้านบริหาร
• bk tree เป็น snapshot จากโค้ดล่าสุดที่ merge เข้าเคอร์เนล .. ชื่อ bk มาจาก BitKeeper ซึ่งเป็นซอฟต์แวร์ SCM ที่ใช้ในการจัดการโค้ดของเคอร์เนลทั้งหมด คล้ายๆ CVS, SVN .. ลินุสเลือกใช้ BitKeeper เพราะสะดวกในการจัดการ changeset มากกว่าตัวอื่น .. BitKeeper เป็น commercial software แต่โครงการโอเพนซอร์สใช้งานได้ฟรี (as in free beer)
• ck tree ของ Con Kolivas .. Con รวบรวมแพตช์เพื่องานเดสก์ท็อป/interactive/low latency เป็นหลัก และยังแฮ็ก scheduling ในเคอร์เนลให้เหมาะกับงานเดสก์ท็อป สมัยนึง ck tree เป็นแพตช์เซ็ตที่ทำงานเร็วกว่าวานิลลาจนรู้สึกได้
• mm tree ของ Andrew Morton .. ตอนจะรีลีส 2.6 Linus ชวนให้ Andrew มาช่วย maintain kernel แต่ Andrew ก็แบ่งรับแบ่งสู้ สุดท้ายแล้ว Linus เลยเป็นคน maintain อย่างเป็นทางการ ในขณะที่ Andrew ช่วยรวบรวมแพตช์และแยก mm tree ไว้เพื่อให้ทดสอบกันในทำนองเดียวกับ ac tree / 2.4

นอกจาก tree ยอดนิยมข้างบนนี้ ก็ยังมี patch/patchset อีกเยอะนะ :

• mjb ของ Martin J. Bligh (Scalability)
• wli ของ William Lee Irwin (VM)
• lsm ของ Chris Wright (Linux Security Modules)
• osdl ของ OSDL (database/enterprise-level hacks)
• dj ของ Dave Jones (I/O AGP)
• rmap Rik van Riel (reverse mapping vm)

me:

[kitt@peorth web]$ uname -a
Linux peorth.kitty.in.th 2.6.8.1-ck4 #4
Tue Aug 24 21:30:27 ICT 2004 i686 i686 i386 GNU/Linux

mm4 patch สำหรับ 2.6.8.1 รีลีสแล้ว เร็วดังคาด .. แพตช์ตัวนี้มี experimental code ชุดใหม่เข้ามา ยังไม่ได้ทดสอบในวงกว้าง ใครอยากทดสอบหรือชอบเสี่ยงก็ ดาวน์โหลด ไปใช้ได้

ck4 patch ของ Con Kolivas รีลีสแล้วเหมือนกัน .. แพตช์/จูนสำหรับเดสก์ท็อปเช่นเคย มีแพตช์ workaround kernel กับ cdrecord ไว้แล้วด้วย ใครใช้งาน CD/DVD Writer เอาแพตช์นี้ไปใช้ก่อนระหว่างรอแก้ไขในเคอร์เนลจริงๆ อีกที ในแพตช์เซ็ตมี Reiser4FS ด้วย ว่ากันว่าเร็วโคตรๆ ..

CK แนะนำว่า เคอร์เนล 2.6 ไม่จำเป็นต้องใช้ kernel preemptible ก็ได้ จะ enable หรือ disable ก็ไม่รู้สึกอะไร เพราะ latency ของ 2.6 ถึงไม่มี preempt ก็ต่ำ(กว่า 2.4)อยู่แล้ว การ enable kernel preemptible อาจจะทำให้โปรแกรมบางโปรแกรมทำงานเพี้ยนอีกด้วย ผมก็เจอบ้างเหมือนกัน เช่น NVIDIA ถ้าภาระงานหนักๆ โมดูลจะทำงานอืดอย่างเห็นได้ชัด ALSA เองก็จะกระตุกๆๆ เท่าที่มีการรายงานบางจังหวะแย่ถึงขนาด latency เกิน 50 msec ก็มี ..

เพื่อแก้ปัญหานี้ Ingo Molnar กับ Arjan van de Ven (@ Red Hat) เสนอโมเดลและแพตช์ชื่อ “Voluntary Kernel Preemption” มาเสริมการทำงานของเคอร์เนล 2.6 .. วิธีการคือดึงเอาจังหวะ might_sleep() ในเคอร์เนลมาใช้ + แก้ไขโค้ด จัด schedule ใหม่ (ผมเดาว่า การใช้ might_sleep() คงเป็นที่มาของคำว่า voluntary – เพราะจุดที่เรียก might_sleep() แปลว่ามันอาสาที่จะ sleep แล้ว) .. การทดสอบ voluntary kernel preemption โดยตัว Ingo เองได้ latency ออกมาไม่ถึง 1 ms แม้จะอัดภาระงานเข้าไปเต็มๆ แล้วก็ตาม .. ตัวเลข 1 msec นี่ถือว่าเทียบเท่าหรืออาจจะดีกว่าเคอร์เนล 2.4 + low latency patch ของ Andrew Morton ที่กลุ่ม Linux Audio นิยมใช้กันเสียอีก :)

อย่างไรก็ตามแฮ็กเกอร์บางคน (i.e., Christoph Hellwig, Andrea Arcangeli) ก็ไม่ค่อยจะเห็นด้วยกับการใช้จังหวะ might_sleep() มา reschedule / preempt เพราะโดยหลักการแล้ว might_sleep() มีนิยามในการทำงานของมันเอง และถ้าจะทำอะไรกับ scheduling ก็มี cond_resched() API ให้ใช้อยู่แล้ว .. Ingo ก็ยอมรับว่ามันมีผลดีผลเสียที่ต้อง tradeoff กันอยู่ ที่เสนอให้ใช้ might_sleep() ก็เพราะมันได้ผลที่ดี ประหยัดกว่า และปลอดภัยกว่า .. จะใช้หรือไม่ก็ตัดสินใจเอาเอง โดยสรุป voluntary kernel preepmtion จะเหมาะกับเครื่องที่ต้องการ latency ต่ำๆ ต้องการการตอบสนองที่ดี เช่น digital audio/video workstation แต่อาจจะไม่เหมาะกับเซิร์ฟเวอร์ที่ต้องการทรูพุตสูงๆ .. voluntary kernel preemption สามารถ enable/disable ขณะที่เครื่องทำงานอยู่ได้ตลอดเวลาผ่านทาง /proc ..

ระหว่างนี้ Ingo กำลังทำแพตช์อีกตัวนึงเพื่อปรับปรุง kernel preemption โดยแพตช์ที่จะออกตามมานี้จะจูน preemption ในระดับ per-task ได้เลย :)

Onamae wa 秋本 Akimoto (autumn book) 直樹 Naoki (straight tree)… ลอล.. มีคนเล่าให้ฟังนานแล้วว่ามีเว็บตั้งชื่อภาษาญี่ปุ่น .. เพิ่งได้ลองเล่น หลังอ่าน blog ของ bact’ .. เอาไปเล่นกัน: Name Generator

ไม่ได้เขียนอะไรเข้าห้องทดลองซะนาน วันนี้เพิ่มเรื่อง วิธีตั้งโดเมนภาษาไทย .. ใครมีโดเมน .th ในมือ สนใจก็ลองทำดูได้ครับ :)

สมาชิก #tlwg ได้ลอง KDE 3.3 แล้วบอกว่า ทำงานเร็วกว่า GNOME 2.6 อีก แถมฟีเจอร์เพียบ .. อืมม น่าสนใจ แต่ตอนนี้ก็ได้แต่รออ่านรีวิว จะ emerge มาลองก็กำลังเร่ง build แพ็กเกจอยู่ ไม่อยากกวนซีพียู .. ยังไงผมก็คงไม่ใช้ KDE อยู่ดี :P

.. กำลังสนใจ x86-64 ของ AMD ซึ่งออกชิป 64-bit มาเพียบจนงงไปหมด .. สอบถาม sf-alpha + กูเกิ้ลได้ความว่า ซีพียูตระกูล x86-64 ของ AMD มีสองรุ่นคือ

• AMD Opteron แยกเป็น Opteron for Server และ Opteron for Workstation และยังแยกออกเป็น 3 series คือ 100 (1-way) 200 (up to 2-way) และ 800 (up to 8-way) .. เมื่อเร็วๆ นี้เพิ่งได้อ่าน ผลเปรียบเทียบประสิทธิภาพของ Opteron 150 กับ Xeon 3.6 GHz บนลินุกซ์ ผลคือ Opteron 150 กิน Xeon เกือบทุกรายการที่ทดสอบ .. ก็นะ .. ของมันแรง :P
• AMD Athlon 64 ประกอบด้วย Athlon 64 สำหรับเครื่องเดสก์ท็อป Mobile Athlon 64 สำหรับโน้ตบุ๊ค และ Athlon 64 FX ออกมาชน Extreme Edition ของ Intel สำหรับเดสก์ท็อประดับ hi-end desktop เกมส์ ฯลฯ ..

ทั้งหมดนี่ที่พอจะหาได้ในบ้านเราก็มี Athlon 64 3000+ หรือ 3200+ ตัวละหมื่นกว่าบาท .. ส่วนเมนบอร์ดก็ราวๆ หกพัน สรุปว่า จะใช้ 64 บิตตอนนี้ ต่อให้มีตังค์ก็ไม่ได้หาซื้อกันได้ง่ายๆ นัก .. รออีกสักพัก เก็บตังค์ไปด้วย :P

นักกีฬาไทยได้เหรียญทองที่สองในโอลิมปิก :D

win32 codecs loading problem: ที่ผ่านมาลินุกซ์บางเครื่องไม่สามารถใช้งาน win32 codecs ได้ไม่ว่าจะผ่านทาง mplayer หรือ xine .. เรื่องนี้เคยเกิดกับผมเหมือนกัน เป็นๆ หายๆ อยู่พักนึง ก็เลยพยายามกูเกิ้ลจนพบว่า ปัญหานี้เกิดจาก combination ของ prelink + exec-shield + โปรแกรมที่ใช้งาน win32 codecs .. อธิบายนิดฟีเจอร์ exec-shield เพิ่มเข้าไปในเคอร์เนลเมื่อปีที่แล้ว (โดย Ingo Molnar @ Red Hat) exec-shield จะ remap address เวลาโหลดไลบรารีเป็นการป้องกัน buffer/stack/pointer overflow attack .. เดิม address remapping ทำโดยการสุ่มพื้นที่เวลาโหลดไลบรารี .. ภายหลัง Red Hat ก็เอาฟีเจอร์ prelink มาใช้งาน การสุ่มพื้นที่เลยเปลี่ยนไปทำตอน full prelink ซึ่งปกติจะทำงานทุกสองสัปดาห์ (อันนี้เองที่เป็นสาเหตุว่าทำไมมันเป็นๆ หายๆ) .. โอเค ร่ายมายาว ประเด็นคือ dll ใน win32codecs หลายๆ ตัวจำเป็นต้องโหลดลงพื้นที่ๆ กำหนดไว้เท่านั้น (e.g., 0x400000) ถ้า exec-shield/prelink เลือกโหลดไลบรารีบางตัวในพื้นที่ไปแล้ว ก็จะไม่สามารถโหลด win32codecs ได้ ผลก็จะกลายเป็น segmentation fault .. วิธีแก้ คือ ยกเลิกการใช้ exec-shield แล้วทำ full prelink โดย

แก้ไฟล์ /etc/sysconfig/prelink จาก

PRELINK_OPTS=-mR

เป็น

PRELINK_OPTS="-mR --no-exec-shield"

** สังเกตดีๆ อย่าลืมใส่ double quote

สร้างไฟล์ เป็นแฟล็กสำหรับ force full prelink

touch /var/lib/misc/prelink.force

สั่ง prelink

/etc/cron.daily/prelink

รอพักนึง

set executable stack flag สำหรับโปรแกรมที่ใช้ win32codecs i.e., mplayer, xine

execstack -s /usr/bin/mplayer
execstack -s /usr/bin/xine

ขั้นตอนนี้เท่าที่ลอง บางครั้งก็ไม่ต้องทำ YMMV ..

ข้อเสียของวิธีนี้คือ มีความเสี่ยงกับ overflow attack มากกว่าระบบปกติ .. tradeoff กันเอาเองเน้อะ (ref: http://mplayerhq.hu/DOCS/HTML/en/faq.html )

cdrecord กับ kernel 2.6.8.1: ใช้งานร่วมกันแล้วมีปัญหา cdrecord ไม่สามารถส่งคำสั่งผ่านเคอร์เนลไปเขียนซีดีได้ .. workaround คือถอยกลับไปใช้ 2.6.7 หรือใช้ cdrecord as root (me: setuid เอาก็ไม่ได้) .. fix ใช้แพตช์ (ตามหาใน LKML เอาเอง :p) หรือไม่ก็รอ mm-patch หรือเคอร์เนลตัวถัดไป .. OT: สำหรับคนที่อยู่กับ LKML มานานพอสมควร เห็นหัวข้อ cdrecord มาพร้อมกับ kernel คงพอเดาได้ว่าจะเกิดอะไรขึ้น .. Joerg Schilling (คนเขียน cdrecord) เป็นโปรแกรมเมอร์ที่เก่ง แต่พี่แกไม่ฟังใครเลย เอาแต่ใจเป็นที่สุด .. ครั้งนี้ก็เช่นกัน ต่อความยาวสาวความยืดกับ Jens Axboe (@ SuSE – kernel hacker – I/O) เรื่องเดิมๆ อีกแล้ว .. ลอล

Keyboard ของ peorth เจ๊ง: ยกไปเซอร์วิสที่ Zeer รังสิต คราวที่แล้วไปเคลมฮาร์ดดิสก์พนักงาน Acer Service ที่ Zeer พูดจาแย่มาก ผมเดินออกมาเลย รวย ไม่เคลมก็ได้ ไม่ง้อหรอกเว้ย .. เที่ยวนี้ดีขึ้น เลยเอาดิสก์ไปเคลมด้วยเลย นึกว่าจะได้ “สู้ว๊อย” ซะแล้ว .. ลอล .. anyway, อะไหล่ไม่มี เลยเอาเครื่องกลับมาใช้งานก่อน ..

kernel 2.6.8.1: มีผลของ make oldconfig (จาก 2.6.7-mm5) อีกเครื่องนึงมาเพิ่มเติม

• Message Signaling Interrupts (MSI and MSI-X)
• Sensor: Analog Device ADM1025 and compatible
• Sensor: Analog Device ADM1031 and compatible
• Sensor: National Semiconductor LM77