ความลับใต้ทะเลสาบ

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

ความลับใต้ทะเลสาบ แปลจากเรื่อง Lakeside ของฮินาชิโนะ เคโงะ โดยคุณบัณฑิต ประดิษธานุวงษ์ เคโงะเป็นวิศวกรที่ผันตัวมาเป็นนักเขียน และทำงานเขียนได้ดังเปรี้ยงปร้างในเวลาอันรวดเร็ว เป็นเคโงะคนนี้แหละที่แต่งเรื่อง Himitsu หรือ Naoko หรือ “ความลับ” ในชื่อภาษาไทย ที่เคย blog ไว้ก่อนหน้านี้ แม้เรื่องนี้เขียนออกเป็นแนวอาชญนิยาย แต่สังเกตพบว่ามีรากที่เกี่ยวข้องกับความรัก คล้ายกับเรื่องความลับ แถมด้วยอารมณ์ happy ending ที่ขุ่นๆ มัวๆ เหมือนเฉลยไม่สุดยังไงชอบกล .. จะว่าไปแล้วเวลาอ่านสองเรื่องนี้อาจไม่ต้องพยายามคิดหรือหาเฉลยให้มากนักก็ได้ .. เจตนาของเคโงะเหมือนจะต้องการให้ผู้อ่านรู้สึกไปกับตัวละครหลักเสียมากกว่า .. YMMV !

เรื่อง Lakeside ได้รับการนำไปสร้างเป็นภาพยนตร์ในชื่อ レイクサイドマーダーケース (Lakeside Murder Case)

Bluetooth Headset on Linux

เปิดหูฟังบลูทูธก่อน จากนั้นก็

$ hcitool scanning

ควรจะเจอหูฟังบลูทูธ ทีนี้แก้ไฟล์ ~/.asoundrc

pcm.bluetooth {
        type bluetooth
        device xx:xx:xx:xx:xx:xx
}

ใส่ address ลงไปตรง xx:xx:xx:xx:xx:xx จากนั้นลอง

$ mplayer -ao alsa:device=bluetooth file.ogg

ควรจะมี balloon ขึ้นมาตรง bluetooth manager ให้ pair device กดที่ balloon แล้วก็ใส่ PIN ให้ถูก ทีนี้มันก็จะเล่นเพลงได้ละ :D

โปรแกรมอื่นๆ ถ้า config device ของ ALSA เป็น bluetooth ก็ควรจะเล่นได้เหมือนกัน .. :)

ลองไปอย่างนั้นแหละ สุดท้ายก็ใช้ลำโพง/หูฟังเหมือนเดิม :P

An IPv6-only network and DNS

ไม่นานมานี้ในการประชุม IETF ได้ปิด IPv4 network ในงานทั้งหมดแล้วให้วิ่งเฉพาะ IPv6 .. ดูเหมือนจะราบรื่นดี ก็ไม่แปลกใจเท่าไหร่ เขาคงเตรียมตัวไม่ให้เกิดเหตุหน้าแตก

เวลาไล่เลี่ยกัน ที่ทำงานข้าน้อยมีปัญหากับสายไฟเบอร์ที่ใช้งานอินเทอร์เน็ต (IPv4) โดนหนูกัดไปหลายสิบคอร์ เสาร์-อาทิตย์มีการซ่อมแซมสายทำให้ใช้อินเทอร์เน็ตไม่ได้ไป 2 วัน .. โชคยังดี (มั้ง) ที่เหลือเส้นสำรองที่วิ่งเป็น IPv6 เพียวๆ .. ตกอยู่ในสถานการณ์ IPv6-only เหมือนกันแบบไม่ตั้งใจ เลยลองใช้ IPv6 อย่างเดียวกันดู

จริงๆ ได้เซ็ตเครือข่าย IPv6 ไว้ที่ทำงานนานแล้ว ใครจะใช้งานก็ง่ายมาก ถ้าระบบปฏิบัติการที่ใช้สนับสนุน IPv6 แค่เชื่อมเข้าเครือข่ายที่จัดไว้ให้ได้ ที่เหลือก็เข้ากลไก stateless address autoconfig. ก็ใช้งานได้ .. สำหรับวันที่ทดสอบ ระบบก็ทำงานได้ราบรื่นดี จนกระทั่งมาตายที่ DNS .. ลอง dig +trace ดูก็พบกว่าถ้า query ผ่าน DNS server มักไม่ค่อยจะได้คำตอบกลับมา หรืออาจจะไม่ได้คำตอบเลย .. สาเหตุเข้าใจว่า root servers ปัจจุบันยังไม่สนับสนุน IPv6 ทุกตัว ข้อมูลล่าสุดที่ ftp://ftp.internic.net/domain/named.root วันที่ 4 ก.พ. 51 (2008020400) มีแค่เซิร์ฟเวอร์ A, F, H, J, K, และ M เท่านั้นที่มีเรคคอร์ด AAAA .. ถ้าเจอตัวที่มี IPv6 address ก็ dig ต่อได้ ถ้าไม่เจอก็จอดเลย .. และถึงจะ dig ต่อได้ ก็ใช่ว่าจะได้คำตอบ เดี๋ยวนี้ root servers มันไม่ได้เก็บ gTLD แล้ว แต่จะกระจาย gTLD ลงมาอีกชั้นที่ gtld-servers.net อีกสิบสามตัว (A – M) เท่าที่ query ดูมีแค่ gtld-servers A กับ M เท่านั้นที่มีเรคคอร์ด AAAA .. จะใช้ IPv6 กับ gTLD ตอนนี้ก็ต้องรอไปก่อนแหละ ฝั่ง ccTLD ก็ลำบากพอๆ กัน ยังไม่นับว่าบางโซนมีเรคคอร์ด AAAA ไว้แล้ว แต่เซิร์ฟเวอร์กลับไม่ได้รัน IPv6 ก็มี .. (- -)a

DNS สำหรับ IPv6 ยังมีอีกปัญหาใหญ่ คือ RFC1035 (STD13) กำหนดไว้ว่าขนาดของ DNS query/reply UDP payload จำกัดไว้ที่ 512 octets ซึ่งทำให้ root zone มี A record ได้ไม่เกิน 13 records ..ถ้ายัด AAAA ไปอีกทุกตัวก็เกินข้อกำหนดแน่ๆ .. ทางออกของปัญหานี้มีแล้ว คือใช้ EDNS(0) ซึ่ง BIND ก็มีให้ใช้ ลองกันหน่อยก็ได้

$ dig NS .
...
;; MSG SIZE  rcvd: 500

เทียบกับ

$ dig +edns=0 NS .
...
;; MSG SIZE  rcvd: 615

หรือ

$dig +bufsize=1024 NS .
...
;; MSG SIZE  rcvd: 615

จะเห็นว่าสองกรณีหลัง MSG SIZE ขนาดเกิน 512 octets … แต่การใช้งานแบบนี้ยังไม่แพร่หลาย เครือข่ายบางแห่งบางที่ก็กรองไว้ แถมทำอะไรกับ buffer บน BIND นี่มันเสียวๆ อยู่แฮะ .. เอาเป็นว่าทำเท่าที่ทำได้ละกัน ไอ้ที่อยู่เหนือการควบคุม ก็ได้แต่หวังให้มันมีความก้าวหน้าไวๆ

แถมท้าย .. root zone มี A 13 records ไม่ได้หมายความว่าจะมี root servers แค่ 13 เครื่องนะ .. root servers เขาใช้ anycast กันหลายตัวแล้ว .. และที่หลายคนอาจจะยังไม่รู้คือ i.root-servers.net หนึ่งใน 13 root servers อยู่ในประเทศไทยตั้งแต่ปี 2004 โน่น .. และถ้าอยากเห็นว่า root servers กระจายอยู่ที่ไหนบ้าง สามารถ ดูบน Google Maps ได้ด้วย :)

มิเกะเนะโกะ โฮล์มส์ ตอน ชมรมวิญญาณคนเถื่อน

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

ชมรมวิญญาณคนเถื่อน แปลมาจาก 三毛猫ホームズの幽霊クラブ ของอาคากะวา จิโร โดยคุณสมเกียรติ เชวงกิจวณิช เจ้าเก่า .. อ่านสนุก มุกขำๆ ตามแบบแผนของซีรีส์แมวสามสี :)

Heads Up .. End-of-Life is coming !

สุดอายุขัยกันอีกแล้ว

  • Debian 3.1 Sarge End-of-Life วันที่ 31 มี.ค. 2551
  • Ubuntu 6.10 EoL วันที่ 24 เม.ย. 2551
  • Fedora 7 EoL = วันที่รีลีส Fedora 9 + 1 เดือน .. ถ้าเป็นตามตารางก็ 29 พ.ค. 2551
  • SUSE 10.1 EoL วันที่ 30 พ.ค. 2551
  • FreeBSD 5.5 จะถึง EoL วันที่ 31 พ.ค. 2551 เนื่องจาก RELENG_5_5 เป็น branch สุดท้ายของ RELENG_5 ก็จะถือว่าวันเดียวกันนี้เป็นการสิ้นสุด branch RELENG_5 ด้วย
  • FreeBSD 6.1 และ 6.2 ก็จะ EoL วันที่ 31 พ.ค. 2551 เหมือนกัน แต่ RELENG_6 ยังอยู่ต่อไปอีกอย่างน้อยเท่ากับ branch สุดท้ายของ RELENG_6 + 2 ปี

ใครใช้ Ubuntu 6.10 ก็มีคำแนะนำให้รออัปเกรดเป็นเวอร์ชัน 8.04 LTS ไปเลยก็ได้ (ตามแผน 8.04 LTS ก็จะ รีลีสวันที่ 24 เม.ย. 51 เหมือนกัน) .. Ubuntu 8.04 LTS จะเป็นรีลีส Long Term Support ต่อจาก Ubuntu 6.06 LTS แต่ถ้าไม่ได้ต้องการฟีเจอร์ในซอฟต์แวร์เวอร์ชันใหม่ๆ ก็ไม่จำเป็นต้องอัปเกรดในทันทีก็ได้ เพราะ LTS ยังไงก็ยังมี support ยาวๆ 3 ปี (desktop) หรือ 5 ปี (server) อยู่แล้ว กว่า 6.06 LTS จะ EoL ก็ปี 2009/2011 โน่น

ส่วนใครที่ใช้ FreeBSD รุ่นที่จะ EoL อยู่แนะนำให้อัปเกรดเป็น FreeBSD 6.3 หรือ 7.0 .. ข่าวของ FreeBSD ส่งผ่าน mailing list วันที่ 1 เม.ย. 51 พอดี .. เลยต้องลงปัจฉิมลิขิตไว้หน่อย ..

P.S. For clarity, this is NOT an April Fool’s joke.

กร๊าก .. :D

OOXML approved

ในที่สุด ISO ก็ประกาศรับรอง OOXML เป็นมาตรฐาน ISO/IEC DIS 29500 ข่าวนี้ลือกันตั้งแต่ 31 มี.ค. และเริ่มมีการหาข่าวยืนยันตั้งแต่นั้น เพราะดันคาบเกี่ยวกับ April Fool’s .. ณ เวลานี้ น่าจะยืนยันได้แล้วจาก press release ของไมโครซอฟต์ และ ECMA รวมถึงเอกสารผลโหวตที่เริ่มมีให้เห็นบนเว็บ

Office Open XML ร่างและผลักดันให้เป็นมาตรฐานโดยไมโครซอฟต์ ซึ่งมาชนกับ Open Document Format (ODF) ที่ผ่านการรองรับเป็นมาตรฐานไปก่อนหน้านี้ มีเหตุผลหลายประการที่ OOXML ไม่ควรเป็นมาตรฐานนานาชาติ ทั้งความซ้ำซ้อนกับมาตรฐาน ODF ที่มีอยู่แล้ว และความไม่โปร่งใสในเชิงเทคนิคของตัว OOXML เอง .. แต่ที่สุดแล้วผลโหวตก็เป็นอย่างที่เห็น ..

  • ประเทศ principal (P-Member) โหวตสนับสนุน 24 จาก 32 ประเทศ = 75% (เกณฑ์กำหนดไว้ว่าต้องมากกว่า 2 ใน 3)
  • ประเทศสมาชิกทั้งหมด โหวตค้าน 10 จาก 71 ประเทศ = 14% (เกณฑ์กำหนดไว้ว่าต้องน้อยกว่า 1 ใน 4)

ทั้งนี้ประเทศที่งดออกเสียงจะไม่นำมาคิดรวม แต่สรุปได้ว่าผ่านเกณฑ์ทั้งสนับสนุนและค้าน ถือว่าผ่านการรับรอง

และที่ควรทราบไว้คือ ประเทศไทย (โดยสำนักงานมาตรฐานผลิตภัณฑ์อุตสาหกรรม: TISI) เป็นหนึ่งในประเทศที่มีการเปลี่ยนมติจาก ‘Disapproval’ ในรอบ fast track เป็น ‘Approval’ ในรอบ BRM

ใน /. มี comment ที่มุมมองน่าสนใจอยู่เหมือนกัน ขออนุญาต quote (+ แก้ข้อความให้ถูกต้องขึ้น)

  1. if they lost the ISO process then they lost
  2. they won the ISO process then they lost as it forced a deep examination of the standard, and raised critical questions and caused them more problems then it solved.
  3. if nobody else implements this flawed standard then they lose as some governments are now also specifying cross platform implementation as well as open standard (perhaps in response to this mess)
  4. if (and this is real unlikely) there are other implementations of this standard (e.g. OO.o) then they lose as MS Office is no longer required to be ubiquitous on the desktop

… สงครามนี้ยังไม่จบ อย่าเพิ่งรีบนับศพทหาร …

Google on 2008-04-01

กูเกิ้ลเผยรายละเอียดโครงการ Virgle .. อภิมหา mega (giga or tera or peta or exa or ..) project ของกูเกิ้ลและเวอร์จิ้นชวนชาวโลกไปสร้างถิ่นฐานบนดาวอังคาร ฟังสารจากผู้ก่อตั้ง เพจ บริน และ แบรนสัน ได้ที่ http://www.youtube.com/projectvirgle และหาข้อมูลเพิ่มเติมที่ http://www.google.com/virgle/index.html

ไม่ต้องกลัวเจ้านายด่าเพราะส่งงานช้าแล้ว .. gmail มีบริการ custom time สำหรับส่งเมลย้อนหลังได้ :D … http://mail.google.com/mail/help/customtime/index.html

กองสลากฯ หนาวแน่ .. กูเกิ้ลออสเตรเลียเปิดบริการ gDay เสิร์ชเอ็นจิ้นสำหรับค้นหาเว็บล่วงได้ 24 ชั่วโมงก่อนข้อมูลนั้นจะถูกสร้างขึ้นมาบนเว็บ เชิญๆ http://www.google.com.au/intl/en/gday/index.html

etc. etc. etc. …

ดูเรื่องอื่นๆ ได้ที่ Google’s Hoaxes .. ปีนึงก็ให้เขาบ้าสักวันเถอะน่า … :D :D

Linux, Mac OS X, and Clock

ว่าจะแก้ปัญหานี้มาตั้งนานแล้ว .. เครื่องข้าน้อยติดตั้งระบบปฏิบัติการไว้สองตัวคือลินุกซ์กับ Mac OS X .. เรื่องของเรื่องคือเวลาอยู่ในลินุกซ์แล้วบูตเข้า Mac OS X ทีไร เวลามันเกินไป 7 ชั่วโมงทุกที ในทางกลับกัน ถ้าเวลาใน Mac OS X ถูก พอบูตเข้าลินุกซ์ทีไรเวลามันหายไป 7 ชั่วโมงทุกทีอีกเหมือนกัน ทั้งที่ตั้ง time zone ไว้ถูกต้องทั้งสองระบบ .. คงเดาได้ไม่ยากเท่าไหร่ว่าต้นเหตุมาจาก Mac OS X กับลินุกซ์มันตีความ hardware clock (aka. RTC, BIOS clock, CMOS clock) ที่บันทึกไว้ในเครื่องไม่เหมือนกัน ดูเหมือน Mac OS X จะเห็น hardware clock เป็น UTC เสมอ แล้วค่อยมาปรับเป็น local time ตาม time zone ในขณะที่ลินุกซ์กำหนดได้ว่าจะตีความ hardware clock เป็น UTC หรือ local time ก็ได้ ขึ้นกับว่ากำหนดไว้แบบไหน .. กรณีของข้าน้อยติดตั้ง Ubuntu แล้วกำหนดไว้ว่า hardware clock เก็บเป็น local time มันก็เลยตีความไม่เหมือนกับใน Mac OS X .. วิธีแก้ ? ไม่ยาก ตั้งลินุกซ์ให้อ่าน hardware clock เป็น UTC ด้วยก็จบเรื่อง .. หลังจากไล่ๆ ดูใน /etc ก็เจอว่ามันกำหนดค่าไว้ใน /etc/default/rcS .. แก้

UTC=no

เป็น

UTC=yes

เรียบร้อย .. ลองรีบูตทั้งสองระบบก็ได้เวลาตรงกันแล้ว :D