ไลนัสแสดงความเห็นว่า shared library นั้นสร้างปัญหามากกว่าประโยชน์ระหว่างการพูดคุยแก้ปัญหา clang ในเคอร์เนลทำงานได้ช้า ขณะที่ดิสโทรสำคัญอย่าง Fedora นั้นมีนโยบายบังคับให้แพ็กเกจต่างๆ ที่ใช้ไลบรารีจากแพ็กเกจอื่นต้องลิงก์แบบ dynamic เท่านั้น
ไลบรารี dynamic หรือไฟล์ .dll บนวินโดวส์และ .so บนลินุกซ์ เป็นไลบรารีที่คอมไฟล์ไว้ล่วงหน้าแต่ไม่ใช่ไฟล์พร้อมรัน (executable) ด้วยตัวเอง แต่ต้องให้โปรแกรมอื่นๆ มารวมเอาไลบรารีเข้าไปเมื่อโหลดโปรแกรม การทำงานเช่นนี้ทำให้ระบบปฎิบัติการสามารถใส่ไลบรารีไว้เพียงชุดเดียว หลังจากนั้นทุกโปรแกรมก็สามารถใช้ไลบรารีร่วมกันได้ ทำให้ประหยัดพื้นที่ดิสก์และหน่วยความจำ
ไลนัสแย้งว่าหากไม่ใช่ไลบรารีแกนกลางจริงๆ เช่นไลบรารี GUI อย่าง Gnome หรือ Qt แล้วอัตราการใช้ไลบรารีซ้ำกันนั้นน้อยมาก จนทำให้ดิสก์ที่ประหยัดได้มีเพียงเล็กน้อยเท่านั้น ส่วนการประหยัดหน่วยความจำก็น้อยมากและหลายครั้งก็เปลืองหน่วยความจำกว่าเดิม
พร้อมกันนั้นไลนัสชี้ปัญหาของไลบรารี dynamic ว่ามีโครงการจำนวนมากสร้างไลบรารีที่ไม่มีคนอื่นใช้งานยกเว้นแต่โปรแกรมบางตัวเท่านั้ แต่โครงการก็ต้องคอมไพล์ไลบรารี dynamic ออกมา แม้การใช้งานจริงจะต้องใช้งานกับตัวโปรแกรมที่เวอร์ชั่นตรงกันเท่านั้น
ที่มา - kernel.org
ภาพการทำงานของ linker โดย Qef
Comments
มันดีตรงไม่ต้องโหลดเพิ่มไง อย่าง .net 4 หรือ vc runtime งี้ เวลาเอาโปรแกรมไป deploy มันไม่ต้องมาลงซ้ำ ยิ่งถ้า .net framework มากับ windows อยู่แล้ว ยิ่งสบาย บางที่ client ติด proxy ยิ่งลำบากกว่าเดิมอีก
.net ก็นับเป็น library แกนกลางไงครับ
ถ้าเป็นเกมเมอร์น่าจะเคยเจอ C++ Runtime โผล่มาเต็มหน้า add or remove program ตลกร้ายกว่าคือพอเอาออกเหลือตัวเดียวที่เป็นปีล่าสุดกลับรันได้ทุกเกมอยู่ดี
I need healing.
อีกอย่าง shared lib บางตัวก็อินดี้เกิน เล่นเปลี่ยน function กันตั้งแต่กลางเวอร์ชันแล้วพาลทำให้แอปบางตัวพัง ทำงานไม่ได้อีก ต้องกลับไปดึงเวอร์ชันเก่ามาทับแบบ hard-code ไปลุ้นอีกทีตอน update
บาง lib เล่นดัดแปลงแยกจากต้นน้ำแล้วไม่ทำแพ็กเกจแยกชื่อกันก็ไปชนกับ lib เก่า พาลทำโปรแกรมเดิมพังไปด้วย แต่เอาจริงๆ ก็ไม่ควรแยกตั้งแต่แรก
ถ้าคิดว่าเป็นปัญหา แล้วทางแก้ที่เสนอคือ ? อย่าบอกนะว่าไม่มี
ถ้ายังไม่มีวิธีที่ดีกว่าตอนนี้ ก็แปลว่าที่ใช้กันอยู่ตอนนี้คือดีที่สุดแล้วรึเปล่า
ทางแก้คือคนทำโปรแกรมรวมเอา library ยิบย่อยที่เคยแยกก็เอามารวมในโปรเจคเลยไงครับ
มันมองจากคนละมุมครับ
ที่ packager บอกว่าดีเพราะตัวเองจะได้ไม่ต้องตามแก้ทุก software ที่ depends กับ library ตัวนั้น
ส่วน linus ก็บ่นกับ rule ของ fedora ที่ทุก library ต้องเป็น share library มันไม่ make sense กับของที่ไม่ค่อยได้แชร์
ปัญหาคือถ้าเป็น share library เพิ่มงานฝั่ง developer แก้ของบางอย่างที่ควรแก้ไม่ได้ง่าย
ถ้าเป็น static library เพิ่มงานฝั่ง packager ที่ต้อง compile software ใหม่ และ user ต้อง download data เพิ่มเยอะขึ้น
ก็นั่นแหล่ะครับ ต่างฝ่ายก็เอาตัวเองเป็นที่ตั้ง แก้ปัญหาฝ่ายนึงแต่ไปสร้างปัญหาให้อีกฝ่ายนึง มันก็ไม่ถูก แต่ถ้าแบ่งๆปัญหากันไปแต่ละฝ่าย รวมๆกันแล้วทุกฝ่ายยังทำงานกันได้ แบบที่เป็นอยู่ตอนนี้ เพราะ Share Library ก็ไม่ได้เพิ่งมีมาสองสามปีซะหน่อยแต่ใช้กันมาตั้งกี่สิบปีแล้ว อยู่ๆจะมามีปัญหาเพราะบางคนบ่น ก็ใช่เรื่อง
ผมว่าเหตุผลของ linus เขาก็มีน้ำหนักอยู่นะ
ถ้าจะใช้ shared ก็ให้ใช้กับที่มันควรจะเป็นจริงๆ
ไม่ใช่ใช้ตะพึดตะพือ
นอกจากสร้างภาระเพิ่มมันยังไม่เกิดประโยชน์ใดๆอีก
ดูจากเหตุผลของ linus อันนี้เขาพุดถึง End-User ด้วยนะ
ปัญหาของ static library คืออะไรเหรอครับ ?? กินที่เยอะ ? กินเมมโมรี่เยอะ จะบอกว่าทำให้เกิด library เดียวกันในระบบหลายเวอร์ชั่นแล้วเป็นปัญหาก็ไม่เชิง เพราะว่าหลาย ๆ lib ก็ไม่ได้การันตี ABI
ผมว่านโยบายที่บังคับทุก lib เป็น shared lib นี่ไม่ค่อยเมคเซนส์เท่าไหร่นะ
โอเค สงสัยผมอาจจะนึกถึงการใช้ Share Library แบบกว้างๆมากไป ไม่ใช่เฉพาะแต่ฝั่ง programmer
แต่ถ้าจับเอาเฉพาะประเด็นในเฉพาะข่าวนี้ ที่ Fedora บังคับเป็น share lib ทั้งหมด เรื่องที่บ่น ก็เห็นด้วยตามนั้น
go ก็มีแนวคิดคล้ายๆกัน โดยไม่ใช้ dynamic link ใช้ static link พวก share lib ก็ include source มาแบบพวก ภาษา script แล้ว compile เป็น binary เดียวกัน
ตอนตอมไพล์ก็ static link เข้าไปเลยครับ งานน้อยกว่าทำ dynamic link เยอะ
lewcpe.com, @wasonliw