เดสก์ท็อปที่สร้างขึ้นเพื่อคนเพียงคนเดียว

 (isene.org)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังผ่านไป 25 ปี โปรแกรมที่ใช้ในชีวิตประจำวันเกือบทั้งหมดถูกเปลี่ยนเป็นเครื่องมือที่ออกแบบขึ้นเอง และมอบหมายให้ Claude Code เพิ่มฟีเจอร์และแก้บั๊ก เพื่อค่อย ๆ แทนที่เครื่องมืออเนกประสงค์เดิมทีละตัว
  • สภาพแวดล้อมทั้งหมดแบ่งเป็นชั้นฐาน CHasm ที่จัดการพิกเซลและอินพุตคีย์ด้วยแอสเซมบลี x86_64 ล้วนโดยไม่ใช้ libc และชั้นแอปพลิเคชัน Rust คือ Fe₂O₃ บน crust
  • ในชั้น CHasm, i3-wm ถูกแทนที่ด้วย tile, kitty ถูกแทนที่ด้วย glass, zsh และ rsh ถูกแทนที่ด้วย bare, และ less ถูกแทนที่ด้วย show
  • ในชั้น Fe₂O₃, VIM ที่ใช้มานาน 25 ปีถูกแทนที่ด้วย scribe ภายใน 72 ชั่วโมงหลังคอมมิตแรก และเครื่องมือสำหรับจัดการไฟล์ อีเมล RSS ปฏิทิน แผงดาราศาสตร์ และภาพยนตร์ ก็ถูกเปลี่ยนเป็นเครื่องมือที่ปรับให้เข้ากับเวิร์กโฟลว์ส่วนตัว
  • BYOS(Build Your Own Software) กลายเป็นทางเลือกที่เป็นจริงมากขึ้นด้วย Rust, Claude Code และปัญหาการเขียนโปรแกรม TUI ที่มีเอกสารรองรับอย่างดี ทำให้สามารถเปลี่ยนเครื่องมือให้ตรงกับผู้ใช้เพียงคนเดียวได้ในระดับสุดสัปดาห์

สภาพแวดล้อมเดสก์ท็อปที่สร้างเอง

  • เป็นครั้งแรกในรอบ 25 ปีที่โปรแกรมในชีวิตประจำวันเกือบทั้งหมดถูกเปลี่ยนเป็นเครื่องมือที่ออกแบบขึ้นเอง
  • ไม่ได้เปลี่ยนเครื่องมืออเนกประสงค์เดิมทั้งหมดในครั้งเดียว แต่ค่อย ๆ แทนที่ทีละตัวด้วยวิธีที่เข้ามือกว่า
  • ใช้ Claude Code ช่วยเพิ่มฟีเจอร์และแก้บั๊ก โดยสั่งงานสั้น ๆ ระหว่างไปทำอย่างอื่น แล้วกลับมารับช่วงจากผลลัพธ์ที่ได้
  • สภาพแวดล้อมทั้งหมดแบ่งเป็นสองชั้น
    • CHasm: ชั้นฐานที่สร้างด้วยแอสเซมบลี x86_64 ล้วนโดยไม่ใช้ libc ทำหน้าที่วาดพิกเซลและอ่านอินพุตจากคีย์บอร์ด
    • Fe₂O₃: ชั้นแอปพลิเคชัน Rust ที่อยู่บน crust ซึ่งเป็นไลบรารี TUI ขนาดเล็กที่ใช้ร่วมกัน

ชั้น CHasm: เครื่องมือที่อิงแอสเซมบลี

  • ตัวจัดการหน้าต่างเปลี่ยนจาก i3-wm เป็น tile
  • แถบสถานะและถาดระบบเปลี่ยนจาก i3bar และ conky เป็น strip และ asmites
  • การล็อกหน้าจอเปลี่ยนจาก i3lock เป็น bolt
  • เทอร์มินัลอีมูเลเตอร์เปลี่ยนจาก kitty เป็น glass
  • ล็อกอินเชลล์เปลี่ยนผ่านจาก zsh และ rsh มาเป็น bare
  • ตัวดูไฟล์เปลี่ยนจาก less เป็น show

ชั้น Fe₂O₃: เครื่องมือบน Rust และ crust

  • โปรแกรมแก้ไขข้อความเปลี่ยนจาก VIM เป็น scribe
  • ตัวจัดการไฟล์เปลี่ยนผ่านจาก ranger และ RTFM มาเป็น pointer
  • อีเมล RSS และแชต เปลี่ยนจาก mutt, newsbeuter และการล็อกอินผ่านเว็บหลายแบบ มาเป็น kastrup
  • ปฏิทินเปลี่ยนจากเว็บของ Google และ MS มาเป็น tock
  • แผงดาราศาสตร์เปลี่ยนจาก astropanel เป็น astro
  • เครื่องมือสำหรับภาพยนตร์และซีรีส์เปลี่ยนจาก IMDB-terminal เป็น watchit
  • เครื่องมือภายนอกที่ยังเหลืออยู่มีเพียง WeeChat สำหรับ IRC และแชตอื่น ๆ กับ Firefox ซึ่งเป็นโปรแกรม GUI ตัวเดียวที่ยังใช้อย่างสม่ำเสมอ

scribe ที่แทน VIM ได้ภายใน 72 ชั่วโมง

  • vim เป็นเครื่องมือหลักที่ใช้มาตั้งแต่ปี 2001 ตลอด 25 ปี สำหรับเขียนอีเมล งานเขียน บล็อก โค้ด HyperList และหนังสือ
  • ความเคยชินระดับกล้ามเนื้อฝังลึกถึงขั้นพิมพ์ :w ในช่องกรอกข้อความทั่วไปของเบราว์เซอร์
  • คอมมิตแรกของ scribe เข้ามาเมื่อวันที่ 1 พฤษภาคม เวลา 00:09 และภายในบ่ายของวันที่ 3 พฤษภาคมก็เข้ามาแทน vim ได้
  • scribe เป็นโมดัลเอดิเตอร์แบบเดียวกับ vim แต่ตัด 90% ของฟีเจอร์ที่ไม่เคยใช้ทิ้งไป และใส่ไว้เฉพาะความสามารถที่ตรงกับเวิร์กโฟลว์ส่วนตัว
    • soft wrap เป็นค่าเริ่มต้น
    • โหมดอ่านแบบมีสมาธิสไตล์ Limelight
    • AI ในพรอมป์ต์ที่ไม่ต้องออกจากบัฟเฟอร์
    • การแก้ไข HyperList พร้อมการเน้นไวยากรณ์ครบทั้งระบบ
    • รองรับฟอร์แมตเข้ารหัสที่ Ruby HyperList app ใช้
    • รีจิสเตอร์แบบคงอยู่ถาวรที่แชร์ข้ามเซสชันพร้อมกันได้
  • มันไม่ใช่ฟีเจอร์ที่ปฏิวัติวงการ แต่ทั้งหมดถูกทำให้ตรงกับเวิร์กโฟลว์ส่วนตัวอย่างแม่นยำ
  • แต่ก่อน ต่อให้รู้ว่าต้องการฟีเจอร์อะไร ก็ต้องรอเป็นเดือน เป็นปี หรืออาจตลอดไป ให้คนพัฒนาอื่นคิดเหมือนกันแล้วใส่มันเข้ามาในเครื่องมือ แต่ตอนนี้การปรับปรุงที่ต้องการอยู่ห่างออกไปเพียงไม่กี่นาที

ต้นทุนของการสร้างเครื่องมือใช้เองลดลง

  • แต่ก่อนการสร้างเอดิเตอร์ ตัวจัดการไฟล์ หรือระบบจัดการหน้าต่างขึ้นมาเอง เป็นโปรเจกต์ที่กินเวลาหลายปี
  • แม้แต่การทำ RTFM ให้ใช้งานได้จริงก็ยังใช้เวลาหลายปี และเป็นงานที่มีต้นทุนสูงมาก
  • สำหรับคนส่วนใหญ่ แม้แต่โปรแกรมเมอร์เอง ก็ไม่คุ้มในเชิงเศรษฐศาสตร์
  • รูปแบบที่พบได้ทั่วไปคือทำไปได้บางส่วน พอสุดสัปดาห์หมดก็กลับไปใช้เครื่องมือสำเร็จรูปเหมือนเดิม
  • แต่ตอนนี้ ด้วย Rust, Claude Code และปัญหาการเขียนโปรแกรม TUI ที่มีเอกสารเพียงพอ ต้นทุนของการ “สร้างเครื่องมือที่อยากได้จริง ๆ ขึ้นมาเอง” ลดลงอย่างมาก
  • ประเด็นสำคัญไม่ใช่ AI หรือ Rust เอง แต่คือช่องว่างระหว่าง “อยากให้เอดิเตอร์ของฉันทำ X ได้” กับ “มีเอดิเตอร์ที่ทำ X ได้อยู่ตรงนี้” หดเล็กลงจนเหลือเพียงการโฟกัสทำงานไม่กี่เย็น

ซอฟต์แวร์ที่ไม่ได้ทำมาเพื่อแจกจ่าย แต่ทำเพื่อคนคนเดียว

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

ความสนุกของการออกแบบเพื่อผู้ใช้เพียงคนเดียว

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

BYOS ในฐานะอีกหนึ่งทางเลือก

  • เมื่อรู้สึกว่าอยากให้เอดิเตอร์ ตัวจัดการไฟล์ แถบสถานะ หรือเชลล์ทำงานต่างออกไปเพียงอย่างเดียว คำตอบก็ไม่จำเป็นต้องเป็นแค่การเขียนปลั๊กอิน การเรียนภาษาคอนฟิกที่ชวนปวดหัว หรือการยอมรับวิธีเดิมต่อไป
  • Build Your Own Software(BYOS) กลายเป็นทางเลือกที่สามที่เป็นจริงมากขึ้น
  • ต่อให้ไม่ได้แทนที่เดสก์ท็อปทั้งชุด แค่มีเครื่องมือสักตัวในเวิร์กโฟลว์ประจำวัน ที่พอดีอย่างแม่นยำ ก็คุ้มค่าพอจะใช้เวลาสุดสัปดาห์ไปกับมัน

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

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

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • ช่วงหลายเดือนที่ผ่านมา ผมคิดเรื่องนี้บ่อยมาก และในโพสต์บล็อกเมื่อไม่กี่เดือนก่อนก็เรียกมันว่า "Extremely Personal Software": https://redfloatplane.lol/blog/14-releasing-software-now/
    ในปี 2026 อาจมีซอฟต์แวร์ใหม่ที่เขียนขึ้นเพื่อคนเพียง 1~10 คนมากกว่าปีไหน ๆ ที่ผ่านมา และมีแนวโน้มว่าจะเป็นแบบนั้นต่อไปอีกหลายปี
    ซอฟต์แวร์จำนวนมากในกลุ่มนี้จะกลายเป็น ซอฟต์แวร์ที่ซ่อนอยู่ โดยพฤตินัย เพราะต้นทุนในการบอกเอเจนต์ต่ำกว่าต้นทุนในการวางแผนออกแบบมาก ผู้คนจึงสร้างมันไว้ใช้เพื่อตัวเอง
    ในอีกไม่กี่ปีข้างหน้า ความสามารถในการทำงานร่วมกันจะยิ่งสำคัญขึ้น และผมก็สงสัยว่าอาจแก้ได้ที่ระดับเอเจนต์/LLM ด้วยคำสั่งถาวรอย่าง "ปกติให้ใช้ sqlite, ใช้ plain text, ใช้มาตรฐานเปิด" หรือไม่
    คนจำนวนมากคงอยากได้ซอฟต์แวร์ส่วนตัว แต่ไม่ได้สนใจเรื่องการบำรุงรักษาและการรันระบบ ดังนั้น observability กับการปฏิบัติการก็น่าจะสำคัญมากด้วย

    • ผมคิดว่าเรียกมันว่าแค่ ซอฟต์แวร์ ก็พอแล้ว
      ตั้งแต่ BASIC ในยุค 1960 เป็นต้นมา รวมถึง ภาษาโปรแกรมเพื่อการศึกษา อีกมากมายอย่าง Logo ของ Feurzeig/Papert/Solomon ก็เป็นความพยายามซ้ำแล้วซ้ำเล่าอย่างน่าประหลาดที่จะทำให้มือใหม่สร้างซอฟต์แวร์ได้
      ความพยายามนั้นไม่ใช่เพื่อ onboarding นักพัฒนามืออาชีพในอนาคต แต่เพื่อทำให้คำว่า "personal" ใน personal computer มีความหมายจริง ๆ
      มันหมายความว่านี่คือคอมพิวเตอร์ของคุณ คุณจึงเอาซอฟต์แวร์ของคุณขึ้นไปรันได้ และจริง ๆ แล้วแม้แต่เครื่องคิดเลขพกพาก็ยังให้ความสามารถแบบนั้น
      พวกเรากำลัง ค้นพบพื้นฐานเดิมซ้ำอีกครั้ง
    • เห็นด้วย ผมเองก็เริ่มสร้างซอฟต์แวร์ให้ตัวเองโดยใช้ Claude แล้ว
      ถ้าไม่มี AI ผมคงไม่มีวันทำแบบนี้ และก็คงไม่มีเวลาด้วย
      ตอนนี้ผมมีแอปที่ปรับแต่งมาเฉพาะทางพร้อมฟีเจอร์หลายอย่างที่ผลิตภัณฑ์เชิงพาณิชย์ให้ได้ไม่ง่ายนัก และเพราะมันเป็นการใช้งานที่ไม่ใช่เชิงพาณิชย์ ตัวเลือกที่เปิดให้ทำได้ก็มีเยอะมาก
      ซอฟต์แวร์เสรีอาจให้สิ่งนี้ได้ในสักวันหนึ่ง แต่ก็น่าจะช้ากว่านั้น
      ระหว่างทางผมก็ได้เรียนรู้อะไรเชิงเทคนิคเยอะมาก และได้สำรวจพื้นที่ที่เคยเป็นของไม่คุ้นเคยสำหรับผมด้วยต้นทุนที่ควบคุมได้
      ต่อจากนี้ก็วางแผนจะทำแอปแบบนี้เพิ่มอีก โดยเฉพาะ แอปทำอาหาร ของผมที่ตรงความต้องการแบบเป๊ะ ๆ จนแทนแอปอื่นในตลาดได้ทันที
      เรื่องการปฏิบัติการก็น่าสนใจ เพราะผู้ใช้ส่วนใหญ่ไม่ได้รันซอฟต์แวร์ปฏิบัติการเอง จึงต้องคิดต่างหาก
      Tailscale กับ Cloudflare มีประโยชน์มาก และตรงนี้มีตลาดชัดเจนแน่นอน
    • ถ้าต้นทุนในการสร้างซอฟต์แวร์ ทั้งในแง่เวลาและกำแพงทักษะ ลดลงอย่างรุนแรง ก็จะเกิด ซอฟต์แวร์ที่เป็นส่วนตัวสุดขีด แบบที่พูดถึงได้
      ยิ่งไปกว่านั้น ผมยังสงสัยว่าเราอาจไปถึงจุดที่คอมพิวเตอร์เขียนซอฟต์แวร์ใช้ครั้งเดียวสำหรับงานของคนเพียง 1 คน แล้วรันมันครั้งเดียวผ่านอินเทอร์เฟซที่เหมาะกับงานนั้นโดยเฉพาะ
      แนวคิดที่ว่าผู้ใช้ต้อง "เรียนรู้วิธีใช้ซอฟต์แวร์" เช่นจำคีย์ลัด อาจหายไปเหมือน บัตรเจาะรู ก็ได้
      เหมือนใน Star Trek ที่เราแค่สั่งงาน "คอมพิวเตอร์" โดยที่กลไกภายในและซอฟต์แวร์มองไม่เห็นสำหรับเรา และเราจัดการแค่ผลลัพธ์
      ยากจะมองผลกระทบทั้งหมดออก แต่แน่นอนว่าทำให้รู้สึกแก่ขึ้นนิด ๆ และช่วงเวลาที่น่าตื่นเต้นกำลังมา
    • ผมก็มีปฏิกิริยาเหมือนกัน ตอนนี้เรากำลังเข้าสู่ยุคที่สามารถปั้นเครื่องมือให้ตรงใจได้เป๊ะ และโดยแก่นแล้วมันใกล้กับ เวิร์กช็อปช่างฝีมือ มากกว่าโรงงาน
      สัญชาตญาณที่ว่าพวกอย่าง API, เลเยอร์ตรวจสอบความถูกต้อง จะสำคัญขึ้นมากก็ดูถูกต้อง
      เครื่องมือภายในบางตัวน่าทำเป็นไลบรารี และถ้าไลบรารีตัวแรกดีพร้อมชุดทดสอบที่พอเพียง การพอร์ตไปหลายภาษาก็จะง่ายมาก
      มองกลับกันก็แปลว่าคนอื่นจะเอาเครื่องมือเฉพาะทางมาต่อเข้ากับไลบรารีนี้ได้ง่ายขึ้นเช่นกัน
      เป็นช่วงเวลาที่น่าตื่นเต้นมากของวงการคอมพิวติ้ง
    • ทำให้นึกถึงบทความบล็อกและงานบรรยาย home cooked software ของ Maggie Appleton
      https://maggieappleton.com/home-cooked-software

  • ผมเพิ่งตระหนักว่าตัวเองก็ใช้ปรัชญาเดียวกันอยู่
    ผมใช้ เครื่องมือแบบ suckless และแก้ st กับ dwm ไปเยอะมากจนตอนนี้รู้สึกเหมือนบ้านแล้ว
    ตอนนี้กำลังลงมือทำ git manager ของตัวเองให้เชื่อมกับ workflow ของผมได้ดี

  • ถึงจะไม่ไปไกลถึงระดับ assembly แต่ผมชอบแนวทางนี้มาก และก็ทำอะไรคล้าย ๆ กันด้วย Ruby
    window manager, shell, terminal, editor, file manager, popup menu ของผม (คล้าย dmenu) เป็น Ruby ล้วนทั้งหมด รวมถึง font rendering และ X11 bindings ด้วย
    พวกนี้เริ่มทำก่อนจะเอา Claude มาช่วยปรับปรุงเสียอีก ดังนั้นโค้ดส่วนใหญ่ยังเขียนด้วยมือ แต่สัดส่วนกำลังเปลี่ยนไป
    มันรก มีบั๊ก และมี "ฟีเจอร์ผิด ๆ" ที่เหมาะกับผมแต่คงทรมานคนอื่น
    เหมือนในโพสต์ต้นฉบับ ผมไม่ได้แนะนำให้คนอื่นมาใช้โค้ดของผมตรง ๆ และนั่นให้ความรู้สึกปลดปล่อยอย่างมาก
    โดยรวมแล้วโปรเจกต์เหล่านี้ครอบคลุมพื้นผิวการใช้งานส่วนใหญ่ที่สุดของสิ่งที่ผมใช้ ยกเว้น kernel, browser และ Xorg
    แม้แต่ Xorg เองก็ชวนให้ลองมาก แต่ถ้าจะให้ทันกรอบเวลาคงต้องรอให้ LLM พัฒนาไปไกลกว่านี้มาก
    เพราะส่วนใหญ่ทำเพื่อตัวผมเอง จึงไม่จำเป็นต้องขัดเกลา และตราบใดที่มันเหมาะกับผมมากกว่าทางเลือกอื่น จะมีบั๊กบ้างก็ไม่เป็นไร
    ผมเชื่อแรง ๆ ว่าคนควรทำแบบนี้กันมากขึ้น มันเป็นประสบการณ์การเรียนรู้ที่ยอดเยี่ยม และได้ระบบที่มีแต่ฟีเจอร์ที่เราอยากได้และใช้จริง
    ต่อจากนี้มันจะยิ่งง่ายขึ้น

  • เจ๋งมาก แต่ก็อยากรู้เหมือนกันว่าใช้เวลาไปเท่าไรและต้นทุนเท่าไรจริง ๆ
    Claude Code ไม่ได้ฟรี และถึงจะเร็วมาก แต่มันก็เหมือนการจ้างผู้รับเหมาหุ่นยนต์ที่คิดค่าจ้างรายชั่วโมงค่อนข้างสูงมากกว่า
    [1]: https://fortune.com/2026/04/28/nvidia-executive-cost-of-ai-is-greater-than-cost-of-employees/
    [2]: https://www.briefs.co/news/uber-torches-entire-2026-ai-budget-on-claude-code-in-four-months/

    • ค่าสมาชิก irccloud.com อยู่ที่ราว 60 ยูโร ต่อปี
      ผมใช้ Claude Pro แพ็กที่ถูกที่สุด, pi.dev+GPT-5.5 และช่วงหลัง ๆ ก็ใช้ deepseek-v4 ผ่าน openrouter เล็กน้อยอยู่ราว 2 สัปดาห์เพื่อทำเวอร์ชันคัสตอมของตัวเอง
      ตอนนี้ความเทียบเท่าด้านฟังก์ชันอยู่ราว 90% แล้ว และบางด้านก็แซงไปแล้วด้วย
      ด้วยเงินราว 20 ยูโร ผมก็กำลังจะมาแทนบริการแบบสมาชิกปีละ 60 ยูโรได้ในไม่ช้า
      ผมไม่เคยคิดแม้แต่วินาทีเดียวว่าคนอื่นจะรันมันอย่างไร ไม่มีระบบล็อกอิน ไม่มีระบบความปลอดภัย ไม่มีอะไรทั้งนั้น
      เพราะมันจะรันอยู่หลัง Tailscale node ที่ไม่มีการเข้าถึงจากภายนอก 100%
      ขั้นตอน release กับ deploy ก็เป็นแบบที่ผมชอบเป๊ะ คนอื่นอาจไม่ชอบก็ได้ แต่ไม่จำเป็นต้องสนใจ เพราะมันเป็นของผม
      ไม่กี่เดือนก่อนผมก็แทนที่ Hazel[0] ด้วยวิธีเดียวกัน
      ตัว MVP น่าจะใช้เวลาแค่เย็นเดียว ส่วนการทำให้สวยงามใช้เวลาสบาย ๆ ราวหนึ่งสัปดาห์
      ตอนนี้ผมมีแอป macOS ของตัวเองที่ทำงานแบบที่เคยต้องใช้ Hazel ได้ตรงเป๊ะ เป็นของผมตลอดไป และจะเพิ่มหรือตัดฟีเจอร์เมื่อไรก็ได้ตามใจ
      [0] https://www.noodlesoft.com/whats-new-in-hazel-6/
    • ผมใช้ Claude Max อยู่แล้ว เลยไม่มีค่าใช้จ่ายเพิ่มนอกเหนือจากค่าสมาชิกที่มีอยู่
      ยังไงก็ต้องเอาไปใช้กับอะไรสักอย่าง
      เรื่องเวลา ถ้านับทั้งชุดซอฟต์แวร์ CHasm กับ Fe2O3 เริ่มตั้งแต่ 2026-03-29 และน่าจะใช้เวลาของผมไปราว 60 ชั่วโมง
      แต่ก็ต้องบอกว่าตั้งแต่หน้าร้อนปีที่แล้ว ผมขัดเกลาการตั้งค่า Claude Code ที่ค่อนข้างเฉพาะทางตามความต้องการของตัวเองมาจากโปรเจกต์ Claude Code กว่า 70 โปรเจกต์แล้ว

  • ผมมี tmux wrapper สำหรับคนคนเดียว
    จากอุปกรณ์ใด ๆ ของผม ผมสามารถควบคุม Claude Code, codex, opencode หรือแค่ shell บนอุปกรณ์อื่นใดก็ได้ผ่าน Tailscale และที่ใช้บ่อยกว่าคือรันผ่านเซิร์ฟเวอร์ exe.dev
    ผมย้าย session ไปต่อบนมือถือบ่อยมาก และบางทีก็ใช้เสียงด้วย
    มีปุ่มสำหรับดูไฟล์ที่เอเจนต์พูดถึงใน text stream หรือเปิดลิงก์ และมีปุ่มสำหรับงาน git แบบที่ผมต้องใช้พอดี
    มีปุ่มสลับระหว่างโหมด yolo กับโหมดปกติด้วย
    โดยพื้นฐานแล้วมันคือ UI ที่เรียบง่ายมากสำหรับทุกอย่างที่ผมใช้จริง และใช้งานบนมือถือได้ง่าย
    และที่อาจสำคัญยิ่งกว่าคือ มันไม่มี UI เลยสำหรับสิ่งที่ผมไม่ได้ใช้เป็นการส่วนตัว
    ทุกเครื่องของผมมี repo harness-harness นี้อยู่ ดังนั้นถ้าต้องแก้อะไร ก็แค่เปิดแท็บ สั่งเป็นพรอมป์ต์ แล้วก็สะท้อนเข้าไปได้ทันที
    ทั้งหมดนี้ดีมาก แต่ข้อเสียอาจเป็นว่ามันทำให้ผมทำงานได้ตลอดทุกชั่วโมงที่ยังตื่นอยู่

    • มีวิธีใช้ การป้อนข้อมูลด้วยเสียง บนสมาร์ตโฟนไหม?
      บน Windows ผมใช้ whisper wrapper แบบ "สำหรับคนคนเดียว" แล้ว SSH เข้าไป ซึ่งก็ทำงานได้พอใช้เพราะมีการ์ดจอ ARC ในโน้ตบุ๊ก
      ถ้าตอน SSH เข้าจากสมาร์ตโฟนทำแบบนั้นได้ด้วยก็คงดี

  • น่าสนใจมากจริง ๆ
    คนที่สร้างของบางส่วนจะเริ่มสร้างสิ่งที่เข้ากับรสนิยมของคนกลุ่มเล็ก ไม่ใช่แค่รสนิยมของตัวเอง
    และคนดูบางกลุ่มในนั้นก็อาจเติบโตต่อไปจนสั่นคลอนผู้เล่นรายใหญ่ได้
    ส่วนที่ ใช้ทุนหนาแน่น ของการสร้างซอฟต์แวร์กำลังละลายหายไป กลายเป็นต้นทุนดำเนินการในรูปค่าโทเคนตามการใช้งานและเวลาของตัวเอง
    สิ่งนี้จะเปิดพื้นที่แห่งความเป็นไปได้อย่างมหาศาล และสร้าง commons ใหม่ขนาดใหญ่
    ถ้าต้นทุนการสร้างถูกขนาดนั้น ก็แทบไม่มีเหตุผลที่จะไม่ปล่อยเป็นโอเพนซอร์ส
    ถ้าคุณชอบโอเพนซอร์สของคนอื่นแต่ไม่อยากยกมาทั้งก้อน ก็แค่บอกเอเจนต์ว่า "เอาไอเดียนี้ใส่เข้าไปในของฉัน"
    มันยังเป็นวิธีคิดใหม่เกี่ยวกับโค้ดด้วย

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

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

  • ยอดเยี่ยม! และก็ไม่ชอบด้วย
    แม้คนสร้างจะยอมรับเองว่าการทำชุดซอฟต์แวร์นี้มี ความสนุก อยู่ แต่คงเป็นความสนุกคนละแบบกับที่หลายคนในนี้จะจำได้
    เหมือนกับ "small web" หรือกระแสต้านวัฒนธรรมอื่น ๆ บนอินเทอร์เน็ต ผมตั้งตารอจะเป็นส่วนหนึ่งของกลุ่มคนที่วิจารณ์และยังทำแบบเก่าอยู่
    ผมจินตนาการถึงการเป็นคนคอยเก็บกวาดซากหลังจากคนอื่นพุ่งเข้าใส่ทุกอย่างที่มี AI ช่วยอย่างเต็มตัว แล้วสูญเสียความคิดเชิงวิพากษ์ ทักษะการเขียนโปรแกรม ความรู้ Unix command line ฯลฯ ไป
    ผมก็พอเข้าใจเสน่ห์ของการทุ่มสุดตัวให้ AI และซอฟต์แวร์เฉพาะบุคคลอยู่บ้าง มันค่อนข้าง cyberpunk ดี
    แต่ในมุมมองของซอฟต์แวร์โอเพนซอร์ส ผมคิดว่าข้อเสียมีมากกว่าข้อดีอย่างชัดเจน
    หลักการสำคัญอย่างความเป็นเจ้าของร่วมกันและความทุ่มเทของชุมชนหายไป และแนวทางนี้ถึงขั้นต่อต้านสังคมอย่างรุนแรงด้วยซ้ำ
    ปัญหาเรื่องการบำรุงรักษาเป็นสิ่งที่เลี่ยงไม่ได้ ยังไม่ต้องพูดถึงการพึ่งพาบริษัทเทคโนโลยีรายใหญ่
    ก็แล้วแต่แต่ละคน แต่สำหรับผม นี่ไม่ใช่ทาง

    • ที่ไหนสักแห่ง ผมจำได้ลาง ๆ ว่าอาจเป็นหนึ่งในโพสต์บล็อกนับไม่ถ้วนที่พูดถึงการระเบิดแบบแคมเบรียนของ LLM ครั้งนี้ มีคนบอกว่านักพัฒนาซอฟต์แวร์แบ่งได้เป็นสองพวก
      พวกหนึ่งคือคนที่ "แค่ให้ของชิ้นนั้นมีอยู่ก็พอ" อีกพวกคือคนที่ "อยากให้ของชิ้นนั้นมีอยู่ แต่ก็อยากสร้างเองและเข้าใจมันด้วย"
      คนกลุ่มแรกกำลังสนุกกันมาก
      ส่วนกลุ่มที่สอง ซึ่งก็คือคนอย่างคุณกับผมตามที่อธิบายไว้ข้างบน กำลังระวังตัวและสงสัย
      มันค่อนข้างย้อนแย้งนะ พวกเราเฝ้าดูและอ่านนิยายวิทยาศาสตร์กับไซเบอร์พังก์มาหลายปี แล้วก็ฝันถึงโลกแบบนี้
      เคยมีตอนไหนที่คุณเห็นลูกเรือ Enterprise เขียนโค้ด? เขาแค่บอกคอมพิวเตอร์ว่า "เขียน subroutine มา" ก็จบแล้ว เป็นโลกที่เท่มาก
      แต่พอโลกนั้นมาถึงจริง ๆ กลับกลายเป็นว่า งานเชิงฝีมือ กำลังตกอยู่ในความเสี่ยง และเราก็ไม่ได้ชื่นชมแนวคิดแบบ "แค่ขอแล้วเดินจากไป" ได้อย่างเต็มร้อย
      ผมเองก็กลัวว่าจะสูญเสียความคิดเชิงวิพากษ์ ทักษะดิบ ๆ และสัญชาตญาณด้านการออกแบบ
      บางครั้งก็จินตนาการว่าหลังจาก 2 ปี 3 ปี 5 ปี หรือ 10 ปี จะได้เป็นหนึ่งในคนส่วนน้อยที่ยังไม่ยกการรับรู้ตนเองและงานเชิงฝีมือให้กับเหล่าเจ้าผู้ครองเทคโนโลยี
      แต่สุดท้ายแล้วก็ยังสงสัยว่ามันจะสำคัญอยู่ไหม
      "source code" อาจกลายเป็นเพียงชั้นนามธรรมที่ลึกมากจนไม่มีใครคิดถึงมันอีกต่อไปก็ได้
      เหมือนกับที่พวกเรา 99% ไม่จำเป็นต้องสนใจหรือรู้เลยว่า machine code ที่ส่งออกสุดท้ายทำอะไรและหน้าตาเป็นอย่างไร
      ยังไงตอนนี้ผมก็จะรักษาวิธีคิดของตัวเองไว้ก่อน

  • เวลาคิดว่า "อยากให้อีเมล/เบราว์เซอร์/ปฏิทินของฉันทำ X ได้" หลายครั้งจริง ๆ แล้วติดอยู่ที่ ข้อจำกัดของโปรโตคอล ข้างใต้
    ดังนั้นต่อให้สร้างซอฟต์แวร์ทั้งหมดเอง เวลาต้องโต้ตอบกับโลกภายนอกก็ยังต้องยอมประนีประนอมอยู่ดี