- แม้จะเพิ่มความจุเก็บข้อมูลหลายครั้ง แต่ปริมาณการใช้งานก็เพิ่มตามไปด้วย และในแบบสำรวจ Mastodon ที่มีผู้เข้าร่วม 81 คน ก็มีราวครึ่งหนึ่งที่ใช้ดิสก์ เกิน 75%
- เรื่องนี้อธิบายได้บางส่วนด้วย ตรรกะของเอนโทรปี ที่ว่ามีวิธีไปถึงสภาวะเต็มมากกว่าสภาวะว่าง แต่ก็ยังอธิบายพฤติกรรมของผู้ใช้ได้ไม่ทั้งหมด
- การผัดวันประกันพรุ่งเรื่องการจัดระเบียบจนเกือบถึงขีดจำกัด แล้วค่อยลบออกเท่าที่จำเป็นในตอนนั้น ทำให้ดิสก์อยู่ในสภาพ ใกล้อิ่มตัวตลอดเวลา
- ซอฟต์แวร์ที่ช้าลง หนี้ทางเทคนิคที่สะสม ถนนที่แออัด และตารางงานที่แน่น ก็แสดงรูปแบบเดียวกัน คือจะรับมือก็ต่อเมื่อความเจ็บปวดถึงจุดวิกฤตแล้วเท่านั้น
- หากตั้ง ข้อจำกัดแบบจงใจ ที่เล็กกว่าทรัพยากรทั้งหมด เช่นเดียวกับงบประมาณ ก็จะช่วยหลีกเลี่ยงการปรับแต่งเร็วเกินไป พร้อมทั้งไม่ปล่อยปัญหาไว้จนถึงขีดจำกัด
เหตุใดพื้นที่เก็บข้อมูลจึงเต็มอยู่เรื่อย ๆ
- ไดรฟ์หลักเหลือพื้นที่เพียง 17GB จากทั้งหมด 0.47TB ที่ใช้งานได้ คิดเป็น พื้นที่ว่าง 3% และไดรฟ์ 12TB ที่ติดตั้งเพิ่มก็เหลือเพียง 140GB หรือราว 1%
- พื้นที่เก็บข้อมูลเพิ่มขึ้นเป็นเท่าตัวมาหลายครั้ง ตั้งแต่ราว 80MB ในทศวรรษ 1990 จนถึงหลายสิบ TB แต่ก็ยังถูกใช้งานไปเกือบหมดอยู่ดี
- การที่มีซอฟต์แวร์ช่วยค้นหาไฟล์ที่ควรลบมาตั้งนานแล้ว ก็แสดงให้เห็นว่าปัญหานี้มีอยู่ต่อเนื่องมายาวนาน
- จากผู้ตอบแบบสำรวจ Mastodon 81 คน ราวครึ่งหนึ่งใช้ฮาร์ดไดรฟ์ เกิน 75% ทำให้กรณีที่พื้นที่เก็บข้อมูลเต็มพบได้บ่อยกว่ากรณีที่ยังว่างมาก
- เนื่องจากมีจำนวนสถานะของดิสก์ที่เต็มมากกว่าดิสก์ที่ว่าง จึงอาจตีความแบบ อิงเอนโทรปี ได้ว่า หากเปลี่ยนสถานะแบบสุ่มโดยไม่คำนึงถึงปริมาณข้อมูล ดิสก์ก็จะมุ่งหน้าไปสู่ภาวะอิ่มตัว
- อย่างไรก็ตาม ดิสก์จะยังไม่ถูกมองว่าเป็นปัญหาจนกว่าจะไม่สามารถเก็บเพิ่มได้ และเมื่อถึงจุดนั้นก็มักจะรกเกินกว่าจะตัดสินได้ง่าย ๆ ว่าไฟล์ไหนควรลบ
- ผู้ใช้มักจัดการเพียงเท่าที่พอจะซื้อเวลาได้ แล้วก็หยุด ทำให้ดิสก์กลับไปถึงขีดจำกัดอีกอย่างรวดเร็ว
- ต่อให้เพิ่มความจุเก็บข้อมูลขึ้นอีกหลายลำดับขั้น พฤติกรรมนี้ก็ไม่เปลี่ยน
ขีดจำกัดของความเจ็บปวดและข้อจำกัดแบบจงใจ
- รูปแบบการเลื่อนการรับมือออกไปจนกว่าปัญหาจะทนไม่ไหวแล้วจึงค่อยจัดการ เกิดซ้ำในหลายด้าน
- ซอฟต์แวร์มักไม่ถูกปรับแต่งจนกว่าจะช้าเกินไป จึงมักคงอยู่ในสภาพช้าเป็นส่วนใหญ่
- หนี้ทางเทคนิคจะสะสมไปเรื่อย ๆ จนการทำงานกับโค้ดเจ็บปวดและเลี่ยงการ refactor ไม่ได้
- นักพัฒนาที่ประสบการณ์น้อยอาจถึงขั้นเริ่มใหม่ทั้งหมด ทำให้ codebase ส่วนใหญ่อยู่ในสภาพยุ่งเหยิง
- โครงข่ายถนนมักจะถูกขยายก็ต่อเมื่อการจราจรติดขัดจนรับไม่ไหวแล้ว
- การคุมอาหารก็มักไม่เริ่มจริงจังจนกว่าจะต้องซื้อกางเกงที่ใหญ่ขึ้น
- แม้จะลาออกจากงานประจำมาเป็นเจ้าของกิจการเองจนไม่มีภาระและคำสั่งแบบเดิมแล้ว ตารางงานก็มักยังแน่นพอ ๆ เดิม หรือบางครั้งยิ่งกว่าเดิม
- หากรอจนถึงขีดจำกัด ปริมาณงานที่ต้องจัดการจะมากกว่าการค่อย ๆ แก้ไขระหว่างทางมาก แต่ในทางกลับกัน การปรับแต่งเร็วเกินไป ก็ไม่ใช่สิ่งที่พึงประสงค์เช่นกัน
- หากต้องการปรับสมดุลระหว่างสองปัญหานี้ สามารถใช้ Jevons paradox โดยกำหนด ข้อจำกัดที่ใช้งานจริง ให้เล็กกว่าทรัพยากรที่มีทั้งหมด แล้วค่อยปรับแต่งให้อยู่ในกรอบนั้น
- ในการเงินส่วนบุคคล สิ่งนี้เรียกว่างบประมาณ แต่ในด้านอื่น ๆ หลักการเดียวกันนี้กลับถูกมองข้ามซ้ำแล้วซ้ำเล่า
- หากนำซอฟต์แวร์ไป deploy บน Raspberry Pi แล้วใช้งานจริงพร้อมปรับแต่ง มันก็จะทำงานได้รวดเร็วบน Threadripper ด้วย
- codebase ที่สามารถสำรวจได้ใน Vim บนเทอร์มินัล 80×25 ก็จะยังสำรวจได้ใน IDE สมัยใหม่ที่ทรงพลังเช่นกัน
- เมื่อทรัพยากรและฟีเจอร์เพิ่มขึ้น เราอาจคิดว่าจะทำงานได้มากขึ้น แต่ในความเป็นจริง บางครั้งมันกลับทำให้เรา ทำงานเดิมด้วยต้นทุนที่สูงขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
เป็นข้อจำกัดที่เจ็บปวด แต่ช่วยตัดคำขอ support จากลูกค้าออกไปได้ทั้งประเภท คู่แข่งมักรองรับแค่ Mac กับ Linux หรือปล่อยเฉพาะ Windows แล้วสัญญาว่าจะรองรับ UNIX ภายหลัง พอเห็นพวกเขาต้องรับมือกับคำถามไม่รู้จบจากผู้ใช้ว่า “Linux เมื่อไหร่?” ก็ทำให้โล่งใจได้บ้าง เรายังถูกถามว่า “จะ port ไป BSD เมื่อไหร่?” อยู่ แต่ยังอยู่ในระดับที่รับมือได้
คำสั่ง SIMD รุ่นใหม่ ๆ ก็น่าสนุก แต่ผมตั้งเกณฑ์ของการ optimize ทั้งหมดไว้ที่ Intel Haswell และ AVX2 ใน MacBook Pro รุ่นปี 2015 โค้ดที่ทำงานได้ดีในสภาพแวดล้อมนั้น ทุกวันนี้ก็ยังทำงานได้ดีเหมือนเดิม
ทุกครั้งที่ขยับจาก 256GB เป็น 512GB ปริมาณคอนเทนต์ที่เก็บก็เพิ่มตามไปด้วย มี repository ให้ clone, เพลงให้ดาวน์โหลด, วิดีโอ YouTube กับหนังให้เก็บไม่รู้จบ และพอขยับจาก 720p ไป 1080p กับ 4K ขนาดไฟล์ก็ใหญ่ขึ้น เกมก็อ้วนขึ้นจนต้องลบเกม Steam เกมหนึ่งออกก่อนถึงจะติดตั้งอีกเกมได้ สุดท้ายแล้วนี่เป็นแค่ปรากฏการณ์ง่าย ๆ ว่าเราจะเติมตะกร้าใบปัจจุบันให้ได้มากที่สุดเท่าที่ทำได้ จนกว่าจะได้ตะกร้าที่ใหญ่กว่าหรือเปล่า
ผมจะกด star repository ที่ชอบไว้บน GitHub หรือ Codeberg เป็นต้น หวังว่าสักวันในโลกแบบ federated จะสามารถแชร์ star ข้าม Git forge ต่าง ๆ ได้ จะได้ไม่ต้องมีบัญชีแยกใน GitHub, GitLab, Codeberg ทุกที่ อยากรู้ว่าที่ clone โค้ดเก็บไว้เองนั้นเผื่อกรณี repository หายไปหรือเข้าถึงไม่ได้ใช่ไหม
/nixถ้าไม่ใช่ทันทีหลังติดตั้งใหม่หมดจด ก็แทบจะเต็ม เกิน 90% อยู่เสมอ Nix แสดงมุมมองของนักพัฒนาอย่างชัดเจนว่า คล้ายกับการจัดการหน่วยความจำ คือจะเก็บดิสก์คืนด้วย garbage collection เฉพาะตอนที่ต้องการพื้นที่เท่านั้น build artifact ระหว่างทางหลายเวอร์ชันก็กินพื้นที่มหาศาลเช่นกันmedia server ไม่ได้เต็ม เพราะใช้ RAID แบบ heterogeneous ที่ค่อย ๆ โตขึ้นตลอดหลายปี โดยทุกครั้งที่ไดรฟ์เก่าเสียก็เปลี่ยนเป็นไดรฟ์ที่ใหญ่กว่าในราคาพอ ๆ กัน ความพยายามจะ digitize CD และ DVD ทั้งหมดในบ้านก็เลิกไปแล้ว CD เพลงที่ใช้การบีบอัดแบบ lossless กับเกม Wii ยังมีคุณค่า แต่ HD-DVD ไม่คุ้มเลย
การทำให้ข้อมูลที่มีคุณค่าไม่หายไป โดยปกติคือบันทึกไว้ใน Nix และเก็บไว้ในโฟลเดอร์โปรเจกต์ที่ใช้ Git นั้นยุ่งยาก การดูแลอุปกรณ์ไทม์แมชชีนแบบนี้มาหลายปีใช้ความพยายามมหาศาล แต่ก็รู้สึกเหมือนเป็นวิธีเดียวที่จะจัดการขนาดและความซับซ้อนที่เพิ่มขึ้นไม่หยุดได้