เอเจนต์ SSH ของ VSCode นั้นชวนงง
(fly.io)- Fly.io พยายามผูกเข้ากับ เวิร์กโฟลว์แก้ไขผ่าน Remote SSH ของ VSCode แล้วพบว่า VSCode ไม่ได้ใช้ remote shell แบบเบา ๆ แต่เป็นโครงสร้างที่ติดตั้งและรันเอเจนต์แยกต่างหาก
- การสร้างโค้ดด้วย LLM จะมีประโยชน์มากขึ้นใน ลูปเอเจนต์ ที่เชื่อมต่อกับสภาพแวดล้อมการรัน แต่ก็อาจแตะต้องการตั้งค่าระบบของโน้ตบุ๊กนักพัฒนาได้ จึงจำเป็นต้องมีอินสแตนซ์ Linux ที่ถูกแยกกัก
- Tramp ของ Emacs ขยายความสามารถไปยังสภาพแวดล้อมระยะไกลโดยรันคำสั่ง Bourne shell ในสภาพแวดล้อมแบบโต้ตอบ เช่น SSH แต่ VSCode ใช้ Bash snippet stager เพื่อดาวน์โหลดเอเจนต์และไบนารี Node
- เอเจนต์ของ VSCode ทำงานอยู่บน SSH ที่ทำ port forwarding และสร้าง การเชื่อมต่อ WebSockets ไปยังฟรอนต์เอนด์ VSCode ทำให้สามารถสำรวจไฟล์ แก้ไขไฟล์ใด ๆ รัน shell PTY และทำให้ตัวเองคงอยู่ต่อไปได้
- แค่การอนุญาตให้แก้ไขระยะไกลด้วย VSCode บนเซิร์ฟเวอร์พัฒนาก็เป็นภาระที่มากอยู่แล้ว และหากวิธีนี้ถูกใช้ระหว่างเหตุการณ์ incident บนโปรดักชันก็ยิ่งน่ากังวลกว่าเดิม แต่สำหรับการเชื่อมต่อแบบคัสตอมกับ Fly Machine นั้นสามารถหลีกเลี่ยงโครงสร้างนี้ได้
การแยกกักที่จำเป็นสำหรับลูปเอเจนต์ LLM
- Fly.io สนใจการผสานเข้ากับเวิร์กโฟลว์ที่ VSCode ใช้ SSH เพื่อแก้ไขระยะไกล
- เพราะมีผู้ใช้ VSCode จำนวนมาก โดยเฉพาะ fork ของ VSCode ที่ใช้สร้างโค้ดด้วย LLM
- โค้ดที่ LLM สร้างขึ้นจะมีประโยชน์เมื่อรู้ว่าผู้ใช้กำลังทำอะไร และจะยิ่งมีประสิทธิภาพเมื่อปิดลูปเข้ากับสภาพแวดล้อมการรันได้
- LLM สร้างโค้ด
- โครงสแคฟโฟลด์ของเอเจนต์รันโค้ดนั้น
- โค้ดสร้างข้อผิดพลาด
- เอเจนต์ส่งข้อผิดพลาดกลับไปยัง LLM
- ทำขั้นตอนนี้ซ้ำ
- โครงสร้างนี้อาจเป็น ยาต้านภาพหลอนที่ได้ผลเพียงครึ่งเดียว แต่ก็เสี่ยงเกินไปหากรันแบบนี้โดยตรงบนโน้ตบุ๊กพัฒนา
- LLM อาจแตะต้องซ้ำ ๆ ไม่ใช่แค่โปรเจกต์ Git ที่กำลังทำงานอยู่ แต่รวมถึงการตั้งค่าระบบด้วย
- รูปแบบที่ดีกว่าคือรัน การจัดวางเอเจนต์ แบบลูปปิดบนอินสแตนซ์ Linux สะอาดที่เริ่มทำงานได้ทันที และป้องกันไม่ให้สภาพแวดล้อมนั้นสร้างความเสียหายแก่ผู้ใช้ได้
วิธีทำงานของเอเจนต์ Remote SSH ของ VSCode
- Tramp ของ Emacs เป็นโค้ด Elisp ที่แทบจะเป็นบรรพบุรุษทางความคิดของระบบแก้ไขระยะไกล
- เมื่อเชื่อมเข้ากับสภาพแวดล้อมแบบโต้ตอบที่รันคำสั่ง Bourne shell ได้ เช่น SSH session ก็จะขยายความสามารถของ Emacs ไปยังสภาพแวดล้อมนั้น
- VSCode ก็มีฟีเจอร์คล้าย Tramp เช่นกัน แต่ไม่ได้เป็นโครงสร้างที่ย้าย Tramp แบบลดรูปมาเขียนด้วย TypeScript
- แทนที่จะใช้เพียงเครื่องมือที่มีอยู่เดิมในการเชื่อมต่อระยะไกล VSCode รัน Bash snippet stager เพื่อดาวน์โหลดเอเจนต์
- เอเจนต์นี้รวมชุดติดตั้งไบนารีของ Node ไว้ด้วย
- ตำแหน่งที่ดูเหมือนเป็นซอร์สที่เกี่ยวข้องคือ ไดเรกทอรี server/node ของ microsoft/vscode
- เอเจนต์ทำงานบน SSH ที่ทำ port forwarding และสร้าง การเชื่อมต่อ WebSockets ไปยังฟรอนต์เอนด์ VSCode ที่กำลังรันอยู่
- โปรโตคอลย่อยสามารถเดินสำรวจไฟล์ซิสเต็มได้
- สามารถแก้ไขไฟล์ใด ๆ ได้
- สามารถรันโปรเซส shell PTY ของตัวเองได้
- สามารถทำให้ตัวเองคงอยู่ต่อไปได้
- ในวงการความปลอดภัยมีชื่อเรียกเครื่องมือที่ทำงานในลักษณะนี้ แต่ไม่ขอพูดตรง ๆ เพราะจะไม่ยุติธรรมกับ VSCode
- การอนุญาตให้แก้ไขระยะไกลด้วย VSCode บนเซิร์ฟเวอร์พัฒนานั้นชวนไม่สบายใจ และหากใช้วิธีเดียวกันระหว่าง incident บนโปรดักชัน ความกังวลก็ยิ่งเพิ่มขึ้น
- ตอนสร้างการเชื่อมต่อแบบคัสตอมกับ Fly Machine ไม่จำเป็นต้องกังวลกับโครงสร้างนี้ และจึงมองว่าในความหมายเชิงลึกแล้ว มันไม่ใช่ปัญหาสำคัญ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตอนแรกตั้งใจจะเขียนบทความยาว ๆ สักเดือนหนึ่งเกี่ยวกับซอฟต์แวร์ที่ง่วนอยู่มา 3–4 ปี แต่ Kurt เริ่มกังวลว่าไม่ได้โพสต์อะไรลงบล็อกตั้งแต่เดือนสิงหาคม สุดท้ายเลยตัดสินใจเขียนบทความที่ง่ายที่สุดแทน
แนวคิดคือทำตรงข้ามกับสิ่งที่ทำมาตลอด นั่นคือเขียน บทความใช้แรงน้อย และคิดว่าน่าจะเขียนได้หนึ่งบทความใน 30 นาที นี่ก็แค่เอาสิ่งที่กำลังง่วนอยู่มาเขียนเท่านั้น และอาจคิดเรื่องนี้น้อยกว่าคนอ่านด้วยซ้ำ
ประโยคใน README ที่ว่า “A compromised remote could use the VS Code Remote connection to execute code on your local machine.” ชัดเจนกว่ามาก และข้าง ๆ ข้อควรระวังด้านความปลอดภัย นี้น่าจะมีหมายเลข CVE กำกับอยู่ด้วย
สองบทความแรกที่เห็นตอนนี้ คือบทความ FLAME-Livebook-GPU ของ McCord-Valim กับบทความนี้ที่มีคำว่า “murid” แสดงเส้นทางทางจิตใจของนักพัฒนาได้อย่างตรงจริง ๆ
อาจอนุญาต system binaries ได้ด้วย แต่จะซับซ้อนขึ้น และ VSCode อาจต้องยัดอะไรหลายอย่างไปไว้ฝั่งไคลเอนต์มากขึ้น ลองค้นคร่าว ๆ เห็นตัวเลือก chroot ฝั่งเซิร์ฟเวอร์ ssh แต่ในคู่มือไคลเอนต์ ssh ไม่ค่อยพูดถึง
หรือทางออกอาจเป็นการดาวน์โหลด Docker container บนเครื่องระยะไกล รัน container ที่ mount ไดเรกทอรีระยะไกล แล้ว ssh เข้าไปใน container นั้น
ปัญหาของวิธีซิงก์เฉพาะไฟล์ในไดเรกทอรีย่อยคือ VSCode ยังต้องมีการรันและดีบักบนเครื่องระยะไกลที่มันเริ่มต้นเองด้วย ดังนั้นปลั๊กอินจึงต้องเข้าถึงเครื่องระยะไกลได้ หรือไม่ก็ต้องรันบนเครื่องระยะไกล และการสังเกตโค้ดบางอย่าง ถ้ารันบนเครื่อง local ค่าใช้จ่ายในการซิงก์ไดเรกทอรีย่อยทั้งหมดล่วงหน้าอาจสูงเกินไป
อาจฟังดูไร้เดียงสา แต่ไม่ค่อยเข้าใจว่าทำไมนี่ถึงเป็นปัญหาความปลอดภัย ถ้าสามารถ ssh เข้าเครื่องใดเครื่องหนึ่งและทำ socket port forwarding ได้ ก็เหมือนมีสิทธิ์ทำอย่างอื่นทั้งหมดอยู่แล้ว และ VSCode protocol ก็ดูเหมือนแค่เปิดเผยสิ่งนั้นในรูปแบบที่สะดวกสำหรับพวกเขาเอง
ที่สงสัยคือเหตุผลที่เป็นปัญหาความปลอดภัย เป็นเพราะคนบางคนที่อยู่ในเครือข่ายเดียวกับเครื่องระยะไกล แต่ไม่มีสิทธิ์ SSH สามารถเชื่อมต่อกับพอร์ตที่ถูก forward ผ่าน SSH ได้หรือเปล่า ในมุมผู้ใช้ ระบบ SSH ของ VSCode ทำงานได้ค่อนข้างดีและชอบมัน
sshหรือ PuTTYVSCode ติดตั้ง remote agent บนเครื่องเป้าหมาย ใช้ ssh เป็น transport protocol และบอกว่าจะให้ transport นั้นใช้ร่วมกับผู้ใช้ ถ้ามันทำแค่สิ่งที่ต้องการก็ไม่เป็นไร แต่ระบบแบบ agent ที่เปิดเผย API ตามอำเภอใจ สร้าง attack surface และความเสี่ยงที่ใหญ่กว่าวิธีคุ้นเคยแต่ก็ยังยุ่งยากอย่างการจำลอง terminal บน ssh มาก
protocol บน connection นั้นสามารถเดินดู filesystem แก้ไขไฟล์ใดก็ได้ เปิด shell PTY process ของตัวเอง และทำให้ตัวเองคงอยู่ต่อได้ การที่ไคลเอนต์ ssh เข้าเซิร์ฟเวอร์ระยะไกล ไม่ได้แปลว่าเซิร์ฟเวอร์นั้นจะรันโค้ดใดก็ได้บนไคลเอนต์ อย่างน้อยไคลเอนต์ต้องทำพฤติกรรมบางอย่างอย่างชัดเจน
แต่เป็นปัญหาความปลอดภัยในความหมายเดียวกับที่ “curl | bash” เป็นปัญหาความปลอดภัย เปรียบเทียบที่ใกล้กว่านั้นอาจเป็น curl | bash ใน
bashrcเพราะ agent เชื่อมต่อกับเครือข่ายและรันอยู่ตลอดเวลา รูรั่วใน firewall ของ dev server จึงกลายเป็นรูรั่วใน firewall ของแล็ปท็อปด้วย
ยิ่งรู้ว่า VSCode ทำงานอย่างไร ก็ยิ่งดูเหมือนมันถูกแปะให้พอใช้งานได้ด้วย duct tape กับไอเดียต้องสาปที่สุดเท่าที่นักพัฒนา JavaScript จะนึกออก
แค่ SSH extension ก็มีรูปแบบ workspace URI อยู่สองแบบ แบบหนึ่งแทบจะมีแค่ hostname และอีกแบบเป็นเอกสาร JSON ที่เข้ารหัสเป็นเลขฐานสิบหก ซึ่งแบบหลังจะใช้เมื่อต้องมีข้อมูลเพิ่มเติมอย่างชื่อผู้ใช้เฉพาะ หรือเมื่อ hostname มีตัวพิมพ์ใหญ่
เหตุผลที่จำเป็นจริง ๆ คือพอมันถูกบันทึกใน recent workspace ไม่รู้ทำไมถึงถูกเปลี่ยนเป็นตัวพิมพ์เล็ก
การเชื่อมต่อ SSH ยังรองรับการตั้งค่า extension ที่จะติดตั้งบนเซิร์ฟเวอร์ด้วย แต่ถ้าใส่เยอะเกินไป จะเชื่อมต่อกับ Windows host ไม่ได้ เพราะมันส่งผ่าน CMD เป็น command-line arguments และ CMD มี ขีดจำกัด 8191 ตัวอักษร แล้ว CMD นั้นก็ไปเรียก PowerShell อีกที
สามารถให้ autocomplete และ diagnostics แบบกำหนดเองได้ และยังทำ Go to definition แบบกำหนดเองเพื่อรองรับข้ามภาษาได้ด้วย
หวังว่า Microsoft จะจ้างผมสักไม่กี่เดือน ให้นั่งอยู่มุมหนึ่งแล้วแก้ความเละเทะนี้ให้คลี่คลาย
ผมเคยดูแลเซิร์ฟเวอร์สำหรับวิชาเครือข่าย, binary exploit และระบบโปรแกรมมิงเบื้องต้น เจ้านี่เป็นปัญหาใหญ่จริง ๆ เพราะโทรจันสำหรับเข้าถึงระยะไกลโง่ ๆ ตัวนี้ทำให้นักศึกษาไม่เข้าใจวิธีใช้ OpenSSH client
ผมลองทำหลายอย่างเพื่อแก้ปัญหา ทั้งเขียนไว้ใน motd ของเซิร์ฟเวอร์วิชาว่าอย่าใช้ปลั๊กอินเซิร์ฟเวอร์ระยะไกลของ VSCode และเปิด
ncdu /homeต่อหน้าชั้นเรียนให้ดูว่านักศึกษาที่ใช้ดิสก์เซิร์ฟเวอร์เกิน 100MB ล้วนเป็นผู้ใช้ VSCode แบบไม่มีข้อยกเว้นผมยังตั้งขีดจำกัดโปรเซสของผู้ใช้ไว้ที่ 45 ตัวด้วย เพราะไม่รู้ทำไมโทรจันสำหรับเข้าถึงระยะไกลของ VSCode ถึงใช้โปรเซส Node ราว ๆ 50 ตัวต่อคน ถ้านักศึกษาไม่สนใจ motd และคำเตือนในชั้นเรียน ก็จะติดลิมิต แล้วต้องมาขอให้พวกเราฆ่าโปรเซสให้เพื่อจะเชื่อมต่อใหม่ได้
สุดท้ายผมเปลี่ยนจากการจำกัดจำนวนโปรเซสมาเป็นสคริปต์ที่ฆ่าโทรจันสำหรับเข้าถึงระยะไกล
.vscode-serverทั้งหมดทุก ๆ 10 วินาทีแทนในวิชาที่ผมเป็นผู้ช่วยสอน มีงานให้จัดการ machine code พื้นฐานเพื่อเลียนแบบเครื่องมือ assemble/execute ของ ISA ที่เรียนมา นักศึกษาต้องเข้าใจโครงสร้างไบต์ของไฟล์ด้วยเครื่องมืออย่าง
hexdumpแต่ Sublime กลับ “ใจดี” เรนเดอร์ object file ให้เหมือนการแสดงผลแบบข้อความของ hexdump พร้อมเติมช่องว่างเพื่อให้อ่านง่าย และยังแสดงผลด้วย ลำดับ endian ที่ต่างจากตอนรัน
hexdumpบนเซิร์ฟเวอร์ Linux ของมหาวิทยาลัยทุกเทอมจะมีนักศึกษาสองสามคนมาถามว่าทำไมโค้ดที่เขียนเพื่ออ่านสตริง ASCII อย่าง
AD DE EF BEถึงไปค้นหาข้อความที่ไม่รู้จัก ที่แท้คือพวกเขาไม่ได้ตรวจสอบว่าค่าไบต์จริงเริ่มด้วย 0xDE, 0xAD, 0xBE, 0xEFผมไม่ค่อยแน่ใจว่าทางเลือกในที่นี้คืออะไร การแก้ไขผ่าน SSH ของ VSCode ทำงานได้ดีอย่างน่าทึ่ง และผมเลิกงมกับ vim, nano, micro บนเครื่องระยะไกลไปนานแล้ว
เอเจนต์ทำให้ทำงานได้เงียบ ๆ โดยไม่มาขวาง แทบให้ความรู้สึกเหมือนทำงานบนเครื่อง local และสำหรับผมนี่เป็นข้อดีใหญ่
มันอาจเป็นความเสี่ยงด้านความปลอดภัยได้ แต่ประสบการณ์นักพัฒนานั้นไม่มีอะไรเทียบได้ ผมไม่ได้สนใจมากนักว่า VSCode กำลังฆ่าเอดิเตอร์ตัวไหนอยู่ แค่เครื่องมือไม่มาขวางและปล่อยให้ทำงานได้ก็พอ
มันไม่ deploy ไบนารี แต่อ่านและเขียนไบต์ผ่าน pipe และการรันงานที่มีนัยสำคัญทั้งหมดเกิดขึ้นที่เครื่อง local โดยเฉพาะอย่างยิ่งมันไม่สร้าง persistence ซึ่ง “ปลั๊กอิน VSCode เข้าถึงได้ระหว่างที่เชื่อมต่อผ่าน SSH อยู่” กับ “ปลั๊กอิน VSCode เข้าถึงได้ตลอดไป” นั้นต่างกัน
เวลาทำงานกับ remote หลายตัว พวกเขามักไม่รู้ว่าตอนนี้เชื่อมต่ออยู่ที่ไหน หรือสถานะการเชื่อมต่อเป็นอย่างไร เทอร์มินัลช้า และ persistence ของสถานะเซสชันก็ไม่สม่ำเสมอ
เป็นประสบการณ์ที่แย่กว่าการใช้
tmuxกับ text editor ดี ๆ มาก แถมเซิร์ฟเวอร์ก็หนักมากและปิดไม่เรียบร้อย จนมักมีอินสแตนซ์เซิร์ฟเวอร์เปิดค้างทีละหกตัวอัปเดตครึ่งหนึ่งพัง และบางทีก็เสียเวลาเป็นชั่วโมงเพราะไม่รู้วิธีเข้าโฮสต์ด้วย ssh client จริง ๆ เพื่อเก็บกวาด vscode server ที่เสีย
เราได้เรียนรู้อะไรกัน? ว่ามีการรันโค้ดระยะไกลอยู่? ว่าการไว้ใจเครื่องมือพัฒนาอย่างผิดที่มักทำให้ต้องเสียใจ? ว่าการออกแบบซอฟต์แวร์สมัยใหม่มันเละเทะ? ทั้งหมดนี้ชัดเจนอยู่แล้วถ้าใส่ใจสักนิด
SSH เป็นคำตอบจากยุค 90 มันคือ Telnet ที่เติมฟีเจอร์บางอย่างเข้าไป และแม้จะถูกเรียกว่า “secure” shell แต่ตามตัวอักษรแล้วปลอดภัยน้อยกว่า Telnet+TLS เสียอีก
คนที่คิดว่าในเมื่อมีท่อเชื่อมต่อที่มีเซสชันผู้ใช้อยู่บนเซิร์ฟเวอร์อยู่แล้ว ก็ไม่จำเป็นต้องสร้างโปรโตคอลขนส่งเครือข่ายและการเชื่อมต่อที่ปลอดภัยสำหรับแอปพลิเคชันแยกต่างหาก ได้เอาของแปลก ๆ แต่ได้รับคำชมสารพัดไปวางทับบน SSH
นี่คือผลลัพธ์ของการทิ้งแนวคิดที่ได้เรียนรู้จากระบบปฏิบัติการแบบกระจาย เพิกเฉยต่อการยืนยันตัวตนและการอนุญาตขั้นสูงที่พัฒนากันมา แล้วเลือกสิ่งที่แย่ที่สุดและง่ายที่สุด
“SSH agent” แบบนี้ไม่ได้ไร้เหตุผล เราไม่ได้ขยับเพื่อสร้างเครื่องมือที่ถูกต้องสำหรับงาน และเพราะอย่างนั้นเราจึงยัดสิ่งต่าง ๆ เข้าไปในเครื่องมือเดิมที่ไม่ได้ถูกออกแบบมาเพื่อจุดประสงค์นั้นมากขึ้นเรื่อย ๆ เราไม่มีสิทธิ์ทำเป็นตกใจ
นี่คือโลกที่เราสร้างขึ้น ทุกคนสร้างมันขึ้นมา ไม่ว่าจะด้วยแรงงานหรือการยอมรับเงียบ ๆ ต่อให้ไม่ใช่ SSH ก็เหมือนกันในเรื่องการเมือง การค้า โรงเรียน และทุกอย่างอื่น ๆ เราใช้ชีวิตอยู่ในกองที่เราสุมขึ้นเองทุกวัน และทุกวันที่ไม่ทำอะไร ก็เท่ากับตักดินเพิ่มเข้าไปอีกหนึ่งพลั่ว จะถือพลั่วอยู่ในมือแล้วทำเป็นว่านี่น่าตกใจหรือบ้าบอไม่ได้
ดังนั้นโดยทั่วไป ถ้าอนุญาตการเชื่อมต่อ HTTPS ขาออก ก็ควรอนุญาตการเชื่อมต่อขาออกทั้งหมด ยกเว้น SMTP ด้วย ทราฟฟิกประสงค์ร้ายจริง ๆ ยังไงก็จะถูก tunnel ผ่าน HTTPS อยู่แล้ว และผลที่เหลือก็มีแค่ขัดขวางการปรับใช้โปรโตคอลใหม่ ๆ ที่ไม่ต้องแบกรับความซับซ้อนและความไร้ประสิทธิภาพของ tunnel
ผมอยากให้การล็อกอินเว็บใกล้เคียงกับวิธีที่ SSH ทำมากกว่านี้
ออกไปข้างนอกแล้วแตะหญ้าบ้างเป็นครั้งคราวดีต่อจิตวิญญาณนะ แล้วก็อยากให้เสนอด้วยว่าจะสร้างโปรโตคอล SSH ที่ดีกว่านี้อย่างไร การบ่นโดยไม่มีคำวิจารณ์เชิงสร้างสรรค์แทบไม่มีประโยชน์
คำว่า “SSH agent” ตรงนี้ชวนสับสน เพราะโดยปกติมันหมายถึง daemon ที่แคชโทเคนยืนยันตัวตน
แถมวิธีนั้นยังทำให้ SSH agent ชื่อดังบน macOS พังด้วย: https://github.com/maxgoedjen/secretive/issues/543
เห็นด้วยเต็มที่ว่าการใช้ vscode remote บนเซิร์ฟเวอร์ production เป็นเรื่องบ้าบอ
แต่ฟีเจอร์อื่น ๆ ที่ถูกอธิบายว่า “ไร้สาระ” ฟังดูเหมือนฟีเจอร์ที่คาดหวังได้
ผมมาถึงระดับ staff engineer ใน MAANG แล้ว และคิดว่านี่เป็นระดับที่ยากจะไปถึงได้ด้วย Vim ธรรมดา ๆ เพียงอย่างเดียว แต่ก็เห็น high performer คนอื่น ๆ ยังมีแนวโน้มใช้ Vim หรือ Emacs อยู่
มีนักพัฒนาที่ยอดเยี่ยมจำนวนมากที่ใช้ VCode, JetBrains ฯลฯ แต่ผมคิดว่านิสัยที่ชอบมองหาอุปสรรคในการเริ่มต้น ชอบสำรวจเพื่อแกะ “เวทมนตร์” ของเครื่องมือออก และให้ความสำคัญกับโอเพนซอร์สเต็มรูปแบบกับโปรเจกต์ที่ขับเคลื่อนโดยชุมชนและปรับแต่งได้สูง อธิบายปรากฏการณ์นี้ได้ดีกว่าฟีเจอร์หรือความสะดวกในการใช้งาน
พออ่านว่าการแก้ไขไฟล์ระยะไกลของ VSCode ซับซ้อนแค่ไหน กลับทำให้ผมอยากใช้ VSCode น้อยลง แค่ ssh เข้าไปในเครื่อง แล้วใช้ editor ที่อยู่บนเครื่องนั้นก็พอ
วิธีแก้ของ VSCode ทำงานได้ก็จริง แต่ไม่สง่างาม ไม่ได้ใช้ได้ทั่วไป และพังง่ายกว่า และขอโทษผู้ใช้ Emacs ด้วย แต่ Tramp ก็ยังค่อนข้างแย่มาก และ netrw ก็ไม่ได้ดีกว่า
watchexec+rsyncสามารถเฝ้าดู path ของไฟล์ที่กำหนด และซิงก์เฉพาะสิ่งที่จำเป็นได้อย่างแม่นยำ คุณยังทำงานบน filesystem ในเครื่อง local จึงไม่มี latency ตอนแก้ไข ใช้เครื่องมือ local ได้ทั้งหมด และการซิงก์เสร็จในระดับมิลลิวินาที
ทำให้ไฟล์ที่ลบใน local ถูกลบในเครื่อง remote ได้ด้วย และหลังจากทำงานกับเครื่อง remote เสร็จแล้วก็ยังมีสำเนา local เหลืออยู่เสมอ ซึ่งเป็นส่วนที่ใน Tramp ต้องซิงก์เองตลอด แถมยังไม่ขึ้นกับ editor ด้วย
ฟีเจอร์นี้ของ VS Code พอรู้แล้วว่าจริง ๆ มันทำอะไร ก็รู้สึกไม่สบายใจ
พอเปิด Copilot toolbar ก็เพิ่มขึ้นอีก และข้อความก็พุ่งเข้ามายังจุดที่ผมกำลังจะใช้ Vim แค่ปล่อยให้เห็นโค้ด คิด และเขียน VSCode ทำให้เข้าสู่ ภาวะ flow ได้ยาก
ผมอายุสามสิบกลาง ๆ ตอนมหาวิทยาลัยใช้ emacs แล้วเปลี่ยนมาใช้ vim ที่งานแรก เคยใช้ IntelliJ กับโปรเจกต์ Java ที่พิสดารมาก ๆ แต่ที่เหลือก็ใช้ vim มาตลอด
จะเปิด vim เป็นครั้งคราวเฉพาะตอนต้องจัดการด้วย regex ที่ซับซ้อน
แทนที่จะทำงานร่วมกับเครื่องมือรีโมตที่มีอยู่ VSCode กลับติดตั้งเอเจนต์แบบครอบคลุม ซึ่งรวมถึงการติดตั้งไบนารี Node.js, การเชื่อมต่อ WebSocket ที่ย้อนกลับไปยังฟรอนต์เอนด์ของ VSCode และความสามารถในการเข้าถึงระบบอย่างกว้างขวาง
เอเจนต์ VSCode นี้มีสิทธิ์กว้างมาก ตั้งแต่การสำรวจระบบไฟล์ การแก้ไขไฟล์ การสร้างโปรเซส shell PTY ไปจนถึงความสามารถในการคงตัวเองไว้
ถ้าเป็นฝั่งระยะไกล ก็เข้าใจว่า elisp Tramp เบากว่าในแง่ dependency แต่ก็สงสัยว่าพื้นที่โจมตีต่างกันจริง ๆ มากขนาดนั้นหรือไม่ กล่าวคือไม่แน่ใจว่าไบนารี Node ฝั่งรีโมตมีสิทธิ์อะไรที่ผู้ใช้ซึ่งรันคำสั่ง ssh ใด ๆ ได้ไม่มีหรือเปล่า
ถ้าเป้าหมายเดิมคือการมอบกุญแจทั้งหมดของเครื่องเสมือนแบบชั่วคราวและทิ้งได้ให้ LLM ก็สงสัยว่าเพราะซ็อกเก็ตที่เอเจนต์เปิดไว้ มันอาจแตะไปถึงเครื่องนักพัฒนาที่ตั้งใจจะแยกออกจากกันด้วยหรือไม่
ฟังดูเป็นความคิดบ้า ๆ แต่ตัวเคอร์เนลเองอาจให้เว็บเซิร์ฟเวอร์หรือโปรโตคอลอื่นที่มีการเข้ารหัสและการยืนยันตัวตน แล้วให้ควบคุมทั้งเครื่องโดยตรงผ่าน eBPF ก็ได้ นั่นอาจเป็นพาราไดม์ที่ต่างไปโดยสิ้นเชิงสำหรับการควบคุมระยะไกลแบบไคลเอนต์/เซิร์ฟเวอร์
แน่นอนว่ามันก็อาจกลายเป็น ช่องโหว่ด้านความปลอดภัย ขนาดใหญ่พอให้ Death Star บินผ่านได้เช่นกัน