ต้นฉบับ พร้อมอธิบายวิธีการวัด: http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage
อ้อ ! …เบิ้ลข่าวอีกครั้ง .. GNOME ตองสองรีลีสแล้ว .. http://library.gnome.org/misc/release-notes/2.22 ..
2.6.24 ออกแล้ว
สำหรับคนใช้ macbook (top case แตกๆ) .. อย่าลืม co mactel patch สำหรับ 2.6.24 มา apply patch ด้วยเน้อ
wireless ใช้ ndiswrapper 1.51 ได้ ไม่มีปัญหา
iSight เอา revision 140 มาใช้ + patch อีกนิดหน่อย
--- uvc_driver.c.orig 2007-11-04 20:54:44.000000000 +0700
+++ uvc_driver.c 2008-01-28 20:35:02.000000000 +0700
@@ -1439,7 +1439,7 @@
vdev->dev = &dev->intf->dev;
vdev->type = 0;
vdev->type2 = 0;
- vdev->hardware = 0;
+/* vdev->hardware = 0; */
vdev->minor = -1;
vdev->fops = &uvc_fops;
vdev->release = video_device_release;
ก็จะใช้งาน iSight ได้ แถมได้ขนาด 640×480 และ support suspend/resume ด้วย .. ใช้ Ekiga ได้สบาย ใช้ Cheese ก็ได้ด้วย ไม่ต้องง้อ Photo Booth แว้วว :D
ไม่นานมานี้ที่ http://slashdot.org มี article เรื่อง Ubuntu May Be Killing Your Laptop’s Hard Drive .. เรื่องของเรื่องก็คือ ฮาร์ดดิสก์โน้ตบุ๊คสมัยใหม่จะมีฟีเจอร์ load/unload ซึ่งทำงานคล้ายๆ กับการ park หัวอ่านของดิสก์ วิธีการ load จะเคลื่อนหัวอ่านเข้าหลังจาก spin จานจนได้รอบที่ทำให้หัวอ่านลอย และการ unload ก็จะเคลื่อนหัวเก็บก่อนแล้วค่อย spin down ฟีเจอร์ load/unload มีจำนวนรอบในการทำงานจำกัด ทำบ่อยๆ กลไกมันจะมีความแม่นยำลดลงจนอาจจะเกิดผลเสียกับแผ่นจาน ตัวเลขโดยประมาณคือที่ 600,000 รอบก็จะเริ่มมีอาการไม่ค่อยน่าเชื่อถือ .. พูดง่ายๆ คือ load/unload บ่อยๆ อาจทำให้อายุดิสก์จะสั้นลงได้ .. ทีนี้พวกฮาร์ดดิสก์ของโน้ตบุ๊คที่มี power management ก็มักจะลดการใช้พลังงานอยู่ใน stand-by mode โดยการ spin down หรือไม่ก็ sleep ไปเลย ทำให้ดิสก์ต้อง load/unload อยู่เรื่อยๆ หลังจากอ่าน article แล้วเลยดู load cycle ของเครื่องตัวเองสักหน่อย …
# smartctl -a /dev/sda ... 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 2484 ... 193 Load_Cycle_Count 0x0032 076 076 000 Old_age Always - 248068 ..
เฮือก! ดิสก์ข้าน้อย load/unload ชั่วโมงละ 100 ครั้ง! เป็นไปได้ไงเนี่ยะ! .. คำนวณหยาบๆ ก็ได้คำตอบว่าถ้ายังคงอัตรานี้ ดิสก์อาจหมดอายุขัยในอีก 11 – 12 เดือนข้างหน้า (- -‘)
วิธีแก้ไข ? ตรงไปตรงมาก็ปิด power management ซะ
# hdparm -B 255 -S 0 /dev/sda
ดิสก์บางตัวอาจต้องใช้ -B 254 แทน ส่วนค่า -S 0 จะเป็นการ disable stand-by timeout ถ้าไม่ชอบ ลอง man hdparm เพิ่มเติมเอาละกัน .. เอาคำสั่งนี้ไปใส่ใน /etc/rc.local และ /etc/acpi/resume.d/99-disable-disk-pm.sh เลยก็น่าจะดี … แต่ทำอย่างนี้ไม่ใช่ว่าไม่มีผลเสีย อย่างน้อยเวลาใช้ on-battery ลดลงแน่ๆ
เรื่องนี้มีข้อสังเกตหลายประการที่ทำให้มีการถกต่อไปอีก อย่างแรกคือหัว article ออกจะ FUDs พอสมควร ที่มาของเรื่องนี้เกิดจากการถกกันใน launchpad เลยจั่วหัวเป็น Ubuntu ซะงั้น ที่จริงแล้ว OS ไหนๆ ก็มีปัญหากับกรณีนี้ได้หมดแหละ ในส่วน Ubuntu เองมี script ปรับการทำงานของ power management ที่ส่งผลกับ load cycle จริง แต่มันจะทำงานเฉพาะใน Laptop Mode ซึ่ง disabled by default .. ทีนี้ทำไม load cycle มันวิ่งกระฉูดขนาด 100 cycle ต่อชั่วโมงก็ยังหาคำตอบกันไม่ได้ … อย่างที่สองคือกรณีของข้าน้อย 100 cycle ต่อนาที นี่มันผิดปกติมาก! จะเป็นตัวเลขที่ถูกต้องหรือเปล่าก็ไม่แน่ใจเหมือนกัน .. อย่างที่สามคือถกกันขำๆ ว่างานนี้สงสัย OS vendor สมคบคิดกับบริษัทผลิตดิสก์ทำให้เจ๊งไวจะได้ซื้อดิสก์ใหม่บ่อยๆ .. (- -)a … เอาเข้าไป .. ถ้าดิสก์ยี่ห้อไหนมันเจ๊งง่ายตูก็ไม่ซื้อมาใช้อยู่ดีแหละน่า .. สุดท้าย ค่า -B 255 -S 0 มีผลดีหรือเสียต่อตัวดิสก์เองหรือเปล่าก็ไม่รู้ .. เครื่องใครเครื่องมัน .. ดิสก์ใครดิสก์มัน .. ตัวใครตัวมันล่ะครับ :P
หลายคนคงได้อัปเกรดเป็น Ubuntu 7.10 Gutsy Gibbon กันไปแล้ว
etc. etc.
สรุปว่าน่าใช้ยิ่งกว่าเดิมละกัน :)
รุ่นหน้า Ubuntu 8.04 LTS กลับมาใช้ codename ตัว "H" อีกครั้ง โดยใช้ codename ว่า "Hardy Heron" .. นกกระสาผู้แข็งแกร่ง มาพร้อมกับ support ยาวๆ 3 ปี / 5 ปี .. เซิร์ฟเวอร์ที่ใช้ 6.06 กันอยู่ก็คงได้อัปเกรดซอฟต์แวร์เป็นเวอร์ชันใหม่ๆ กันซะที :)
สังเกตว่าตั้งแต่ Feisty เป็นต้นมา ALSA จะ enable dmix dsnoop softvol by default ทำให้สามารถ playback, record audio ได้หลาย stream ในเวลาเดียวกัน ไม่ต้องใช้ ESD หรือ Sound Daemon อื่นๆ กันแล้ว …. แต่นั่นต้องแลกมาด้วยคุณภาพเสียงที่ลดลง เพราะ dmix dsnoop มันก็คือ mixer software ที่ต้องทำงานโคตรเร็วเพื่อไม่ให้เกิด delay จนรู้สึกได้ แปลว่ามันจะ buffer stream ไว้น้อยมาก mix แล้ว playback ออก คุณภาพมันก็จะไม่ค่อยดี เปิด volume สูงๆ ก็จะมี noise บ้าง เสียงแตกบ้าง .. ถ้าจะเอาคุณภาพดีก็ต้องเพิ่ม buffer ทำให้ delay สูงขึ้นเวลาเล่นเกมภาพไปทางเสียงไปทาง ..
วันนี้นั่งฟังเพลง noise มา left channel มั่ง right channel มั่ง .. ฮึ่ยยย .. อุตส่าห์มี HD Audio ดันมา bottleneck กะ dmix ซะนี่ .. ไม่ทนมันแล้ว เอาออกซะเลยดีกว่า ! .. กะจะพึ่งพา Google หาไปหามา สุดท้ายก็มานั่งเขียน ~/.asoundrc เองเหมือนเดิม (- -‘) ..
เอา Hardware PCM ตูคืนมาเลย !
pcm.!default {
type plug
slave.pcm "plughw:0,0";
}
Reboot เพื่อความชัวร์ .. noise หายเป็นปลิดท้ิง play/record audio ได้ stream เดียวก็ช่าง สบายใจแล้ว :D
มีโอกาสเปลี่ยนมือถือ + palm เป็น HTC Touch เมื่อประมาณ 2-3 สัปดาห์ก่อน .. พยายามหาโปรแกรมนาฬิกาปลุกมาใช้เพราะที่มากับเครื่องมันเสียงเป็นแมลงหวี่ คงไม่ตื่นโดยง่าย แถมใช้ได้เฉพาะ WAV อีกต่ะหาก .. แต่ก็ไม่เจอโปรแกรมฟรีตัวไหนที่มันโดนๆ .. สุดท้ายใช้นาฬิกาปลุกที่มากะเครื่องแต่แปลง ringtone ชื่อ old phone เสียงกรี๊งงงง โคตรดัง จาก WMA เป็น WAV เอาไว้ปลุก
วิธีแปลงอย่างง่ายโดยใช้ mplayer ก็
$ mplayer Ring-OldPhone.wma -ao pcm:file=output.wav
ringtone ที่เอามาแปลงนี้ คุณภาพระดับ 44.1 kHz 16 bit mono ขนาดไฟล์ประมาณ 22 kB .. แปลงเป็นไฟล์ WAV ได้คุณภาพเท่าๆ ต้นฉบับ แต่ไฟล์มันก็จะขนาดบ่ะละเฮิ่มตั้ง 229 kB … เปลืองเด้ .. ลดคุณภาพสักหน่อยละกัน
$ mplayer Ring-OldPhone.wma -af volume=0,resample=22050:0:2 -format u8 -ao pcm:file=output.wav
re-sample ลงเป็น 22.05 kHz 8-bit mono เหลือ 57 kB .. ฟังดูไม่ต่างกันมาก ขนาดไฟล์ก็พอรับได้ .. ตอนนี้เลยได้เสียงปลุกโคตรดังสมใจ แต่จะตื่นหรือไม่นั่นเป็นอีกเรื่องนึง :P
ในที่สุด สิ่งที่ไม่ควรจะเกิดขึ้นก็เกิดขึ้นจนได้ วันที่ 11 ก.ค. 2550 Con Kolivas หนึ่งในเคอร์เนลแฮ็กเกอร์ที่พัฒนาและรวบรวม patch ปรับปรุงการทำงานของลินุกซ์สำหรับระบบเดสก์ท็อปก็ประกาศว่า 2.6.22-ck1 จะเป็น -ck patchset สุดท้าย ต่อจากนี้ไปเขาจะเลิกแฮ็กเคอร์เนลของลินุกซ์แล้ว
เหตุผลสั้นๆ ที่พอจะประเมินได้คือ .. เซ็ง
เหตุผลยาวๆ เริ่มจาก staircase CPU scheduler ที่ CK พัฒนามาก่อนหน้านี้ เริ่มแรก staircase มี bug อื้อเสถียรภาพไม่ดี นักพัฒนาส่วนนึงก็อัด staircase แหลก .. CK ได้ปรับปรุงและเปลี่ยนเป็น staircase deadline (SD) CPU scheduler ในภายหลัง เสถียรภาพของ SD ดีขึ้นมากและผ่านการทดสอบจากผู้ใช้กลุ่มใหญ่พอสมควร มีผู้ใช้สนับสนุนและเรียกร้องให้รับ SD เข้าเคอร์เนลหลัก ..แต่ก็มีแรงต้านทุกครั้งไป .. ในขณะที่ Completely Fair Scheduler (CFS) ซึ่งมีแนวคิดในการทำงานใกล้เคียงกันกับ SD แซงทางโค้งเข้าป้ายไปรวมเข้าในเคอร์เนล 2.6.23 .. คำถามก็เกิดขึ้นในกลุ่มผู้ใช้ -ck ว่า ถ้าไอเดียของ SD มันดี ทำไมไม่ตัดสินใจเลือก SD แล้วมาช่วยกันแก้ปัญหาเสถียรภาพตั้งแต่ตอนโน้น ? ทำไมถึงเกิด CFS ซึ่งมีแนวคิดทับซ้อนกันอีก ?
นอกจากเรื่องของ SD แล้ว Swap Prefetch ก็เป็นอีกหนึ่งงานของ CK ที่โดนวิพากษ์ใน LKML .. patch นี้ค้างอยู่นานแล้ว มีคนทดสอบอยู่พอสมควร ได้รับการตอบสนองในเชิงบวกมาเกือบตลอด และยัง maintain อยู่ใน -mm อีก แต่ก็ไม่ได้รวมเข้าเคอร์เนลหลักเสียที ..
ถ้าทำแล้วไม่ได้รับความสนใจอย่างที่ควรจะเป็น ทำอยู่นานแล้ว ปัญหาที่ต้องแก้ก็แก้ให้หมดแล้ว ยังเข้าเคอร์เนลหลักไม่ได้ จะทำไปอีกทำไม ? แล้วใน LKML น่ะ บทจะมีแรงต้านหรือขัดแย้งกันมันใช่ย่อยเสียที่ไหน แฮ็กเกอร์อัตตาแรงๆ ปากคอร้ายๆ ก็มีให้เห็นอยู่
ผลที่ออกมาก็กลายเป็น .. "พอกันที .. ku ไม่ทำ mang’ ละ .. "
เป็นเรื่องน่าเสียดาย .. แต่อย่างน้อย CK ก็ได้ทิ้งผลงานให้ทำกันต่อ และอันที่จริง CK ก็มีส่วนใน CFS ไม่น้อยเหมือนกันนะ ..
/me thanks CK for his great works,
Link: http://futurist.se/gldt
หลักๆ:
Mac OS X มี Dashboard .. Compiz/Beryl ก็มี Screenlets
เจ๋งเป้ง :D