เคล็ดลับในการจัดโครงสร้างโฮมไดเรกทอรี (2023)

 (unixdigest.com)
2 คะแนน โดย GN⁺ 2024-04-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เคล็ดลับโครงสร้างโฮมไดเรกทอรี

  • การจัดโครงสร้างหรือจัดระเบียบไดเรกทอรีไม่ได้ต่างจากการจัดโครงสร้างหรือจัดระเบียบสิ่งอื่นมากนัก และหัวใจสำคัญคือทำในแบบที่สมเหตุสมผลกับตัวคุณที่สุด
  • เมื่อต้องจัดการเรื่องการจัดระเบียบ มันสามารถหลุดการควบคุมได้อย่างรวดเร็วมาก
  • เป้าหมายหลักของการจัดระเบียบคือประสิทธิภาพ โดยควรค้นหาสิ่งที่ต้องการได้ง่ายและรวดเร็ว และบันทึกสิ่งที่ต้องเก็บได้ง่ายและรวดเร็ว

ไฟล์และไดเรกทอรีพื้นฐานแบบซ่อน

  • ในโฮมไดเรกทอรีของฉันมีไฟล์ซ่อนพื้นฐานทั้งหมดที่เป็นส่วนหนึ่งของระบบปฏิบัติการยูนิกซ์สมัยใหม่ เช่น .config, .aliases, .profile, .gnupg, .mozilla
  • แม้ว่าจะอยากให้ทุกแอปพลิเคชันเคารพ XDG_CONFIG_HOME แต่ก็ไม่ได้เข้าไปก้าวก่ายหรือใส่ใจเรื่องนี้มากเกินไป
  • ในอดีตเคยดูแล $HOME ด้วย Git ซึ่งเป็นวิธีที่ยอดเยี่ยมในการจัดการ Dotfiles
  • ทุกวันนี้ก็ยังเก็บ Dotfiles ทั้งหมดไว้ใน Git เพื่อรักษาประวัติการเปลี่ยนแปลง แต่จะคงไว้แบบเดิมเฉพาะ Dotfiles ที่ทำงานเหมือนกันได้บนหลายระบบที่ใช้งาน
  • Dotfiles เฉพาะการตั้งค่าจะเก็บไว้ในไดเรกทอรี dotfiles และใช้ symbolic link

การจัดองค์ประกอบของไฟล์และไดเรกทอรีทั่วไป

  • ไฟล์และไดเรกทอรีทั่วไปจะจัดโดยใช้สองวิธีหลักคือ "หมวดหมู่" และ "วันที่"
  • โครงสร้างไดเรกทอรีพื้นฐาน:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • คงไดเรกทอรี Desktop และ Downloads ไว้ตามเดิม (เพราะดูเหมือนว่าแอปส่วนใหญ่จะบังคับให้มี)
  • ไดเรกทอรี bin ใช้เก็บ shell script และไฟล์ปฏิบัติการไบนารีส่วนตัว (ไม่รวมสิ่งที่ติดตั้งผ่าน package manager)
  • ไดเรกทอรี mnt ใช้สำหรับจุดเมานต์หลากหลายแบบ เช่น SD card, USB disk และ shared storage ที่ใช้ใน homelab
  • จะไม่ใช้การเมานต์อัตโนมัติโดยเด็ดขาด และใช้ shell script สำหรับการเมานต์แทน
  • ไดเรกทอรี usr/dotfiles ถูกจัดการด้วย Git ร่วมกับ Dotfiles ทั่วไปอย่าง .aliases และใช้ symbolic link ไปยังไฟล์ที่เกี่ยวข้องในไดเรกทอรี dotfiles

การจัดองค์ประกอบของไดเรกทอรีข้อมูล

  • ไดเรกทอรี data และ edata คือสองไดเรกทอรีหลักที่ใช้เก็บข้อมูลทั้งหมด
  • ทั้งสองไดเรกทอรีนี้เป็น ZFS dataset ที่ทำงานอยู่บน disk mirroring pool แยกจาก root installation
  • ใช้ประโยชน์จาก ZFS โดยใช้งาน snapshot รวมถึง ZFS send และ receive เป็นประจำ เพื่อสำรองข้อมูลไปยัง network storage ได้อย่างง่ายดาย
  • ความแตกต่างระหว่าง data และ edata คือ edata เป็น ZFS native encrypted dataset
  • การเข้ารหัสนั้นดีต่อความเป็นส่วนตัว แต่ก็เป็นชั้นความซับซ้อนที่น่าปวดหัวซึ่งซ้อนอยู่บนลำดับชั้นของระบบไฟล์ที่ซับซ้อนอยู่แล้ว และ ZFS encryption ก็มีบั๊กอยู่
  • ขอแนะนำอย่างยิ่งให้สำรองข้อมูลสำคัญไว้เสมอในโซลูชันจัดเก็บและสถานที่หลายแห่งที่แตกต่างกัน
  • ไม่ใช้ cloud storage สำหรับสิ่งที่สำคัญ

เคล็ดลับเพิ่มเติม

  • กฎพื้นฐานสำหรับการตั้งชื่อไฟล์และไดเรกทอรีคือ ควรดูจากชื่อแล้วระบุได้ง่ายว่ามันคืออะไร
  • หากไม่สามารถรู้ได้ว่าไฟล์นั้นเกี่ยวกับอะไรโดยไม่ต้องเปิดดู คุณควรเปิดมันทันทีและเปลี่ยนชื่อให้มีความหมายมากขึ้นเพื่อที่ครั้งหน้าจะเข้าใจได้จากชื่อไฟล์
  • ถ้าปล่อยไฟล์และไดเรกทอรีไว้โดยไม่จัดระเบียบ ภายหลังจะแก้ไขให้เป็นระเบียบได้ยากมาก
  • ใช้ชื่อไฟล์ที่มีคำอธิบายยาวเมื่อจำเป็น เพื่อให้เข้าใจเนื้อหาไฟล์ได้โดยไม่ต้องเปิดดู

ความเห็นจาก GN⁺

  • บทความนี้ให้เคล็ดลับเชิงปฏิบัติในการจัดระเบียบและจัดโครงสร้างไดเรกทอรี โดยเฉพาะแนวทางแบ่งจัดการระหว่างไดเรกทอรีที่เข้ารหัสและไม่เข้ารหัสด้วยการใช้ ZFS dataset ที่น่าสนใจ

  • โดยส่วนตัวคิดว่าการเก็บข้อมูลสำคัญแบบเข้ารหัสเป็นเรื่องที่ดี แต่ก็มีข้อเสียเช่นประสิทธิภาพที่ลดลงหรือความซับซ้อนที่เพิ่มขึ้น จึงดูเหมาะกับการเลือกใช้ตามสถานการณ์

  • อีกประเด็นสำคัญคือควรแบ่งปันวิธีเข้าถึงข้อมูลที่เข้ารหัสไว้กับสมาชิกในครอบครัวด้วย เพื่อไม่ให้ข้อมูลสูญหายแม้ในกรณีที่เจ้าตัวไม่สามารถเข้าถึงได้จากอุบัติเหตุหรือเหตุไม่คาดคิด

  • สำหรับการจัดการข้อมูลส่วนบุคคล การวางกลยุทธ์การสำรองข้อมูลอย่างเป็นระบบเหมือนผู้เขียนถือว่าสำคัญมาก อาจยึดตามกฎสำรองข้อมูล 321 และใช้ local storage ที่กระจายตัวทางกายภาพแทน cloud storage ก็เป็นวิธีที่ดี

  • เครื่องมือโอเพนซอร์ซที่มีประโยชน์สำหรับการจัดการข้อมูลส่วนบุคคล ได้แก่ Syncthing หรือ Nextcloud หากใช้เครื่องมือเหล่านี้ได้ดี ก็จะช่วยให้จัดการข้อมูลส่วนบุคคลได้อย่างเป็นระบบและปลอดภัย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-21
ความคิดเห็นจาก Hacker News

  • ไม่ชอบที่โฮมไดเรกทอรีรก โดยเฉพาะเวลาที่แอปคิดว่าจำเป็นต้องสร้าง ไดเรกทอรีที่ไม่ซ่อนด้วยซ้ำ ไว้ในโฮม น่าหงุดหงิดมาก
    ที่ทำให้โมโหที่สุดคือ ~/go ซึ่งเป็นไดเรกทอรีเริ่มต้นของ Go modules เกลียดมากจนเลี่ยงการติดตั้งหรือพัฒนาแอป Go อยู่หลายปี แต่สุดท้ายก็ต้องใช้ และถึงจะเปลี่ยนได้ด้วยการตั้งค่า GOPATH แต่ค่าเริ่มต้นก็แย่มาก

    • ที่แย่ที่สุดคือเครื่องมือ CLI ที่สร้างบน Mac มักจะเมิน XDG เพราะฝั่งนั้นไม่ใช่แนวคิดที่พบได้ทั่วไป เครื่องมือแต่ละตัวเลยทำให้ dotfiles รกด้วยไดเรกทอรีของตัวเองอย่าง .rustup, .mix, .npm, .yarn
      แต่การทำให้โฮมไดเรกทอรีสกปรกโดยไม่มีมารยาทแม้แต่จะซ่อนเหมือน ~/go นี่ไร้มารยาทจริง ๆ
    • มองว่า GOPATH เองเป็นการออกแบบที่แย่ แทนที่จะมีโครงสร้างไดเรกทอรีแยกอิสระตามแต่ละโปรเจกต์เหมือนภาษาอื่น ๆ กลับทำให้ของจากโปรเจกต์ที่ไม่เกี่ยวข้องกันถูกปนอยู่ในโครงสร้างไดเรกทอรีเดียวกัน
      มันขัดกับวิธีที่ผมจัดระเบียบโปรเจกต์มาก จึงเป็นเหตุผลหลักที่ทำให้ไม่สนใจ Go สำหรับคนที่ชอบรวมหลายโปรเจกต์ที่ไม่เกี่ยวข้องกันไว้ใน monorepo เดียว อาจจะเหมาะกว่า แต่ไม่ใช่รสนิยมของผม
    • เคล็ดลับ: อย่าเอาไฟล์ของตัวเองไว้ใน $HOME เพราะ $HOME คือที่ที่แอปต่าง ๆ ทำให้รก ส่วนไฟล์ของเราก็เอาไปไว้ ที่อื่นไหนก็ได้จริง ๆ
    • เลิกเชื่อเรื่องโฮมไดเรกทอรีที่สะอาดไปนานแล้ว ของสำคัญทั้งหมดเอาไว้ใน ไดเรกทอรีซิงก์ อย่าง pCloud, Dropbox ภายในโฮม แล้วจัดข้างในนั้นให้เป็นระเบียบสมบูรณ์
      ส่วน .vimrc กับ .gitconfig ทำ symbolic link ไปยัง Git repository ไว้ แบบนี้โฮมไดเรกทอรีส่วนที่เหลือจะเป็นขยะทั้งหมดยังไงก็ไม่เป็นไร และถ้าเครื่องพังก็กู้คืนบนเครื่องอื่นได้ภายในไม่กี่นาที
    • ถ้า Unix แยก “โฮมไดเรกทอรีสำหรับสิ่งที่แอปอยากใส่ทั้งหมด” กับ “โฮมไดเรกทอรีที่ผู้ใช้เอาไฟล์ของตัวเองไปไว้” เป็น มาตรฐาน ตั้งแต่แรกก็คงดี

  • xdg-ninja ช่วยลดปัญหาที่แอปส่วนใหญ่เทไฟล์ลงในโฮมไดเรกทอรีได้
    สรุปคือมันสแกนโปรแกรมที่ติดตั้งไว้ แล้วบอกว่าสามารถตั้งค่าให้ทำตามมาตรฐาน XDG ได้ไหม ไม่ได้ใช้ได้กับทุกอย่าง แต่หลายแอปมีตัวเลือกแบบนั้น
    https://github.com/b3nj5m1n/xdg-ninja

  • ไม่ใช่แค่การจัดระเบียบ แต่อยาก สำรองข้อมูลและย้ายข้ามเครื่องอย่างกระชับ ด้วย
    โฟลเดอร์ .config เป็นปัญหาใหญ่เวลาสำรองข้อมูลแบบมีกลยุทธ์ เพราะแอปเอาข้อมูลเซสชันขนาดหลายกิกะไบต์ไปใส่ไว้ในนั้น
    “ข้อมูลเซสชัน” ไม่ใช่ “การตั้งค่า” นะ “การตั้งค่า” ของแอปไม่มีทางมีขนาดหลายกิกะไบต์หรอก

    • ถ้าไม่ได้ขอให้โปรแกรมเปลี่ยนการตั้งค่าถาวร .config ก็ควรทำงานได้แม้เป็น แบบอ่านอย่างเดียว
    • เห็นด้วยมาก ไม่เข้าใจว่าทำไมแอปถึงใช้ .config เหมือนเป็นที่เก็บข้อมูลแอป ทั้งที่สำหรับเรื่องนั้นมี .local กับ .cache อยู่แล้ว

  • เรื่องนี้ส่วนตัวเกินไป วิธีแก้ของผู้เขียนจึงไม่มีประโยชน์กับผม และวิธีแก้ของผมก็คงไม่ได้ช่วยคนอื่นมากนัก
    โฮมไดเรกทอรีของผมแทบว่างเปล่า ไฟล์งานทั้งหมดอยู่ใน OwnCloud และคำถามจริง ๆ คือโครงสร้างไดเรกทอรีใน OwnCloud เป็นอย่างไร ส่วน local Git repository แยกไปอยู่ในพาร์ทิชันคนละส่วนเลย
    ตอนนี้ KeepassXC จัดการ SSH key ได้แล้ว key ใน .ssh ก็เลยย้ายเข้าไปอยู่ในไฟล์ Keepass บน OwnCloud ด้วย มันเรียบง่ายขึ้นมาก และตอนนี้แทบไม่มีอะไรในโฮมไดเรกทอรีที่ต้องใส่ใจจริง ๆ

    • สิ่งสำคัญมีแค่ ความสามารถในการย้ายข้ามระบบ ตอนเปลี่ยนระบบ และการแยกสภาพแวดล้อมงาน/ส่วนตัว
      หลังล็อกอินแล้ว ควรซิงก์ชุดไฟล์ที่เหมาะกับสภาพแวดล้อมปัจจุบันได้ด้วยคำสั่งเดียว ไม่ว่าจะเป็น Linux หรือไม่, เครื่องงานหรือส่วนตัว, เดสก์ท็อปหรือเซิร์ฟเวอร์
      ตัวอย่างเช่น ตัวแปรสภาพแวดล้อมอย่าง endpoint ของ home vault หรือโทเคนเฉพาะบางอย่าง ไม่อยากให้หลุดไปอยู่ในระบบงานเด็ดขาด
      ช่วงหลังย้ายไปใช้ home-manager ของโปรเจกต์ NixOS แล้ว ดูมีอนาคตทีเดียว ภาษา Nix ซับซ้อน แต่ abstraction สำหรับนิยามสภาพแวดล้อมหลากหลายนี่แหละคือสิ่งที่ต้องการพอดี และสามารถแยกเนื้อหาไฟล์งาน/ส่วนตัวด้วย Git branch ได้
    • ถึงอย่างนั้น .vimrc กับ .bashrc/.zshrc ก็ยังไว้ในโฮม

  • แนวคิดก็ใช้ได้ แต่ไม่ค่อยชอบวิธีแบ่งมีเดียตามโครงสร้างแบบครอบครัว ดูเหมือนภายหลังจะมี ไฟล์ซ้ำ กับสำเนาที่ถูกแก้ไขกองเต็มไปหมด และปะปนกันง่ายจนทำให้ไฟล์ฉบับแก้ไขหายได้
    ผมคิดว่ารูปภาพควรจัดระเบียบด้วยคีย์เวิร์ด EXIF มากกว่า เก็บเมทาดาต้าไว้ในตัวรูปภาพเอง หรืออาจจะใน MIME type แล้วถ้าเกี่ยวกับครอบครัวก็ติดแท็กอย่าง #family หรือ #personx ดังนั้นรูปภาพก็วางไว้ในโฟลเดอร์อย่างตามวันที่ ส่วนที่เหลือใช้โปรแกรมอย่าง Adobe Bridge แก้ไขคีย์เวิร์ด
    โครงสร้างชื่อไฟล์เอกสาร ผมลองใช้มาทั้ง Date then Description.txt และ Keyword Title or Description and then Date.txt วันที่ใช้รูปแบบ ISO แบบ YYYY-MM-DD-hhmm เพื่อให้เรียงลำดับได้ และ -hhmm เป็นส่วนที่ใส่หรือไม่ก็ได้
    บางครั้งก็อยากเรียงตามหัวข้อ ซึ่งก็คือคีย์เวิร์ดหรือชื่อเรื่อง แต่ถ้าเวลาที่บันทึกสำคัญกว่า เช่น log การเอาวันที่ไว้ข้างหน้าจะดีกว่า
    อาจดูไม่จำเป็นเพราะวันที่ก็ถูกเก็บไว้ในระบบด้วย แต่พอย้ายไฟล์ไปมา วันที่สุดท้ายก็เปลี่ยนอยู่ดี และถ้าพลาดก็เปลี่ยนได้ง่ายยิ่งกว่า ในทางกลับกัน วันที่ในชื่อไฟล์จะไม่เปลี่ยน และยังช่วยให้เรียงรายการได้ด้วย

    • สำหรับปัญหานี้ ที่เก็บข้อมูลแบบอ้างอิงตามที่อยู่ของเนื้อหา แยกตามประเภทมีเดียน่าจะเป็นทิศทางที่เหมาะ ตามอุดมคติควรเป็น overlay ที่แค่อ้างอิง โดยไม่ต้องเปลี่ยนโครงสร้างไดเรกทอรีหรือการจัดไฟล์เดิม
      photoprism กับ photostructure ดูเหมือนไม่ค่อยสนใจโครงสร้างไดเรกทอรีหรือการจัดระเบียบมากนัก แต่ paperless (รวมถึงตัวแยกรุ่นใหม่อย่าง -ngx) ขึ้นชื่อว่าเจ้าระเบียบเรื่องการจัดเก็บมาก และไม่ค่อยยอมเคารพโครงสร้างเดิม
      เคยใช้ camlistore/perkeep กับรูปภาพอยู่พักหนึ่ง แต่ Google Photos มีความสามารถที่เหนือชั้นมากในการระบุว่าในทุกรูปมีใครบ้าง โดยยังคำนึงถึงความต่างของอายุด้วย ลูกชายสองคนที่อายุห่างกัน 8 ปี ตอนอยู่ในช่วงวัยใกล้กันหน้าตาคล้ายกันมากจริง ๆ แต่มันก็แยกได้ถูกต้องว่าใครเป็นใคร ไม่รู้ว่าใช้การวิเคราะห์ใบหน้าหรือใช้เมทาดาต้าของรูปภาพ แต่ไม่เคยสับสนเลยแม้ครั้งเดียว เพียงแต่ไม่มีวิธีที่สมเหตุสมผลในการดึงข้อมูลแท็กนั้นออกมานอก Google Photos ทั้งที่ผมก็จ่ายเงินอยู่
      ตอนนี้น่าจะถึงเวลากลับไปดูอีกครั้งแล้ว จำไม่ได้ว่า photostructure หรือ photoprism พยายามทำ face recognition ไหม แต่ถึงยังไม่ทำ อีกไม่นานก็น่าจะไปถึงระดับใกล้เคียง Google Photos หรืออย่างน้อยก็ดีพอให้เลิกพึ่ง Google ได้
      เอกสารกับรูปภาพ/วิดีโอก็พอว่า แล้วเพลงล่ะ? ไม่ว่าจะดีหรือแย่ ผมไม่ได้จัดการคอลเลกชันเพลงเป็นไฟล์เองมาอย่างน้อยราว 10 ปีแล้ว สมัยนี้มีระบบไลบรารีสำหรับเพลงที่ผสานกับคอนเทนต์ลึกกว่าแค่ “ไฟล์บนดิสก์” แบบ paperless หรือ photoprism ไหม?
    • ถ้าต้องการจัดการแท็กไฟล์แบบอิสระ ลองใช้ TagSpaces https://www.tagspaces.org/ หรือ TMSU https://tmsu.org/ ได้ ไม่ได้จำกัดเฉพาะไฟล์ EXIF หรือ ID3

  • วิธีของผมเป็นแบบนี้
    รายการที่เกี่ยวกับ GUI ใช้ตัวพิมพ์ใหญ่ ส่วนรายการที่เกี่ยวกับ CLI ใช้ตัวพิมพ์เล็ก ผมชอบแบบ ~/documents มากกว่า แต่คนฝั่ง GUI ยืนกรานจะใช้ตัวพิมพ์ใหญ่ ก็เลยยอมรับไป แทบไม่ต้องเอาสองแบบมาปนกัน จึงไม่ใช่ปัญหาใหญ่
    ~/dotfiles คือไดเรกทอรี dotfiles ที่จัดการด้วย Git ทำ symbolic link อย่าง ~/.zshrc -> dotfiles/zshrc ไม่ใช้ซอฟต์แวร์จัดการแยกต่างหาก แค่ทำลิงก์เฉย ๆ เมื่อก่อนใช้ ~/.dotfiles แต่คิดว่าปล่อยให้มองเห็นได้สมเหตุสมผลกว่า
    ~/projects คือไดเรกทอรีโปรเจกต์ ~/projects/test คือโปรเจกต์ทดสอบแบบใช้ครั้งเดียวเพื่อเช็กอะไรบางอย่าง, ~/projects/my คือโปรเจกต์ส่วนตัว, ~/projects/company คือโปรเจกต์ของบริษัทที่ทำงานอยู่ตอนนี้ บางครั้งทำงานกับหลายบริษัทแบบกึ่งฟรีแลนซ์ เลยต้องแยกไว้
    ~/tmp คือไดเรกทอรีสำหรับงานใช้ครั้งเดียวทั้งหมด ผมมี shell function ชื่อ mkcdtmp ที่สร้างไดเรกทอรีวันที่ปัจจุบันอย่าง ~/tmp/240419 แล้วเข้าไปในนั้น เป็นวิธีที่ดีมาก ผมชอบซื้อดิสก์ใหญ่ ๆ แล้วปล่อยขยะไว้ในสภาพที่ค่อนข้างเป็นระเบียบ จึงแทบไม่เคยล้าง ถ้าต้องการของจากเมื่อวานหรือเดือนก่อน ก็รู้ว่ามันอยู่ที่ไหน และนี่เป็นสิ่งที่ช่วยจัดระเบียบงานชั่วคราวได้มากที่สุด จะสร้าง ~/tmp/whatever เพิ่มก็ได้ถ้าต้องการ เพราะยังไงทั้งหมดก็เป็นของที่ทิ้งได้
    ไม่ใช้ ~/Desktop ส่วน ~/Documents ก็แทบไม่ใช้ และยังต้องหาวิธีจัดระเบียบอยู่ โน้ตสั้น ๆ อะไรทำนองนั้นโยนไว้ใน GitHub repository ที่ใช้ build เว็บไซต์ส่วนตัว ลองใช้แอปโน้ตมาหลายตัวแล้ว แต่เว็บไซต์ธรรมดาที่เขียนด้วย Markdown เหมาะกับผมที่สุด
    ไม่เคยประสบความสำเร็จในการจัดงานให้เป็นโครงสร้างมาก ๆ เลย มักมีแต่กองขยะเลื่อนไปมา แล้วสุดท้ายค่อยกลายเป็นอะไรที่พอใช้ได้ ดังนั้นแทนที่จะสู้กับตัวเอง ผมตัดสินใจทำให้ขยะนั้นเป็นขยะที่มีระเบียบ
    โดยพื้นฐานแล้วคอมพิวเตอร์ของผมคือ ของสิ้นเปลือง ทุกอย่างใน ~/projects อยู่ใน Git และ ~/tmp ก็เป็นเหมือนแคชหรือผลงานที่ทิ้งได้ซึ่งไม่สำคัญนัก ผมพยายามจัดให้กู้คืนจากสถานะสะอาดได้โดยใช้เวลาไม่นาน ผมติดตั้ง OS ใหม่ตั้งแต่ต้นค่อนข้างบ่อย และเปลี่ยนทั้งระบบปฏิบัติการกับแล็ปท็อปบ่อยด้วย วิธีนี้เหมาะกับผมที่สุด

    • ผมเกลียดการเขียนอะไรก็ตามด้วยตัวพิมพ์ใหญ่จริง ๆ รู้ว่าแค่กดเพิ่มอีกปุ่มเดียว แต่ก็น่ารำคาญเหลือเกิน

  • สิ่งหนึ่งที่ไม่พอใจมากในไฟล์ซิสเต็มคือมีไดเรกทอรีมากเกินไปที่ ขึ้นต้นด้วย D
    Desktop, Dev, Downloads, Documents, Dropbox ฯลฯ
    เคยคิดว่าจะเปลี่ยนอะไรดูบ้าง แต่ตามที่ผู้เขียนบอก แอปพลิเคชันจำนวนมากค่อนข้างดื้อกับเรื่องนี้

    • เพื่อเลี่ยงปัญหานี้ ผมใช้ /src

  • ผมใช้โครงสร้างที่ค่อนข้างเรียบง่าย แต่เหมาะกับตัวเองดี
    ใต้ projects/ จะสร้างโฟลเดอร์ตามปี เช่น 2023/, 2024/ แล้วแต่ละโปรเจกต์จะใส่คำนำหน้าเป็นเดือน+วัน เช่น 0000-something/, 0312-other-project/, 0419-hn-comment/
    ทุกปีจะสร้างโฟลเดอร์ปีขึ้นมา และถ้าอยากดันโปรเจกต์ระยะยาวให้ลอยอยู่ด้านบน ก็ใส่ 0000 หรือกำหนดเฉพาะส่วนวันที่เป็น 00
    เรียบง่ายและใช้ได้กับทุก OS ส่วนบน Linux ก็มีใช้สคริปต์ช่วยเล็กน้อย
    ยังสร้างไดเรกทอรีสำหรับย้ายไฟล์จากโฟลเดอร์ดาวน์โหลดได้เร็ว และถ้าคงการซ้อนชั้นไว้แค่ระดับเดียวก็หาได้ง่าย ผมมองว่าดีกว่าวิธีที่เพิ่มชั้นเดือนขึ้นมาอีกชั้นแบบแพตเทิร์น YYYY/MM/DD

    • ผมใช้วิธีคล้ายกันเวลาจัดโฟลเดอร์ที่เกี่ยวข้องกันตามลำดับเวลา
      ในไดเรกทอรีระดับบนสุด ปกติจะวางสิ่งที่กำลังทำอยู่ตอนนี้ เป็นแนวคิดประมาณ “วันนี้” หรือ “สัปดาห์นี้”
      เมื่อจะเก็บถาวรหลังพ้นกรอบเวลานั้นไปแล้ว เช่นถ้าเป็นวันนี้ ก็จะสร้างโฟลเดอร์รูปแบบอย่าง 041924 แล้วก็ย้ายไฟล์ทั้งหมดที่สร้างในวันนั้นเข้าไปในนั้น
      โดยปกติเมื่อมองตามช่วงชีวิตมนุษย์ ผมคิดว่าไม่จำเป็นต้องใช้สตริงอย่าง 2024 เพราะก็คงไม่ได้อยู่ถึงปี 2100 และก่อนปี 2000 ก็ไม่เกี่ยวข้อง ดังนั้น 24 ก็พอแล้ว
      เวลายังคงเดินต่อไป จำนวนโฟลเดอร์เก็บถาวรก็จะเพิ่มขึ้น แต่ขนาดเล็กและค้นหาง่าย เหมาะเป็นพิเศษกับกรณีที่สร้างไฟล์มาตรฐานที่ไม่ได้มีเอกลักษณ์มากนักในแต่ละวัน
    • ใช้ วันที่แก้ไข ของโฟลเดอร์ไม่ได้หรือ? น่าจะเรียงลำดับได้
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • ผมเองก็ย้ายมาใช้แนวทางนี้พร้อมเพิ่มโครงสร้างโฟลเดอร์ที่มีลักษณะเป็น “กระบวนการจัดการ” เข้าไปด้วย ข้อมูลซ้ำซ้อนอาจเพิ่มขึ้น แต่ช่วยรักษาสุขภาพจิตได้

  • เรื่องการสำรองข้อมูล ผมเคยพยายามติดตั้ง Mac เครื่องใหม่จากแบ็กอัป Time Machine แต่ Mac กลับมองไม่เห็นอะไรเลยในแบ็กอัป Time Machine
    พอติดต่อฝ่ายซัพพอร์ตของ Apple ก็ได้ยินมาว่ามีบั๊กที่พบได้น้อย ซึ่งบางครั้งกระบวนการติดตั้งจะ ล้างค่าแบ็กอัป Time Machine แทนที่จะติดตั้งจากแบ็กอัป
    โชคดีที่ตั้งค่า Backblaze ไว้เลยรอดมาได้ แต่การกู้คืนข้อมูลหลายร้อยกิกะไบต์ใช้เวลานานมาก
    ตอนนี้ผมใช้ทั้ง Time Machine, Backblaze และแบ็กอัป iCloud และบางครั้งก็แพ็กทั้งหมดเป็น .tgz แล้วอัปโหลดขึ้น S3

  • เรื่องชื่อไฟล์และชื่อไดเรกทอรี ถ้าต้องเลือกระหว่างขีดกลางกับขีดล่าง ผมเห็นด้วยเต็มที่กับ ขีดกลาง
    การใช้ขีดกลางเวลาเคลื่อนย้ายในเทอร์มินัลนั้นใช้งานได้จริงมากจนผมคิดว่าควรเป็นมาตรฐาน ดีกว่าการต้องพิมพ์เพิ่มทุกครั้งเพื่อเลือกชื่อไฟล์ที่มีขีดล่าง หรือการต้องจัดการกับช่องว่างมาก

    • จุดเล็ก ๆ ที่ผมชอบใน Lisp ก็คือเรื่องนี้ ตั้งชื่อตัวแปรแบบ foo-bar-baz ได้ และไม่ต้องกด Shift ตอนพิมพ์